Merge requests de l'enfer au paradis

Transcript

1. Merge request de l’enfer au paradis SANDRINE BANAS @COSJAVA
7. La merge request et l’agilité
8. Les individus et leurs interactions plus que les processus et les outils La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
9. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
10. Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.
11. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
12. Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
13. La revue de code
14. Le feedback de la MR
15. Lisibilité du code Améliorations syntaxiques Parfois détection d’un oubli d’implémentation -Rarement détection d’un bug, défaut de conception
16. Communiquer son état d’avancement Transfert de connaissances Accompagnement d’un junior Responsabilité collective du code
17. Les alertes sur la route de l’enfer
18. Les MR bloquent plus de 24h
19. Certaines MR ne sont pas relues
20. La même personne lit toutes les MR
21. Des échanges sans fin sur une MR
22. Les modifications en douce post-MR
23. Des MR temporairement fermées
24. Les problèmes de fusion
26. La partie cachée d’une
28. La critique est aisée, et l’art est difficile. Philippe Néricault
29. Que peut-on faire à propos du problème de l’ego dans la programmation ?
30. Comprendre et accepter que vous ferez des erreurs 1.
31. Vous n’êtes pas votre code. 2.
32. La programmation est une compétence comme les autres. Elle s’améliore avec la pratique. Si un pair vous montrait des façons d’améliorer votre jonglage, le prendriez-vous pour une attaque de votre caractère et de votre valeur en tant qu’être humain ? Debugging Teams, Better Productivity through Collaboration Brian W. Fitzpatrick, Ben Collins-Sussman
33. De la même manière, votre valeur personnelle ne devrait pas être liée au code que vous écrivez, ni à aucun projet créatif que vous construisez. Pour nous répéter: vous n'êtes pas votre code. Dites-le encore et encore. Vous n'êtes pas ce que vous faites. Debugging Teams, Better Productivity through Collaboration Brian W. Fitzpatrick, Ben Collins-Sussman
34. Peu importe combien de « karaté » vous connaissez, quelqu’un d’autre en connaitra toujours plus. 3.
35. Ne pas réécrire le code sans consultation 4.
36. Traiter les gens qui en savent moins que vous avec respect, déférence et patience 5.
37. La seule constante dans le monde est le changement. 6.
38. La seule vraie autorité vient du savoir, pas de la position. 7.
39. Battez-vous pour ce en quoi vous croyez, mais acceptez gracieusement la défaite 8.
40. Ne soyez pas « le gars dans la pièce » 9.
41. Critiquer le code plutôt que les personnes. Soyez bienveillant pour le codeur pas pour le code. 10.
43. Petite 250 lignes
44. Single Responsability Principle 1
45. Titre clair Etiquettes
46. Formatage
48. La responsabilité collective du code a de toute façon tendance à éviter que du code compliqué soit ajouté au système. Kent Beck (XP)
49. Si vous savez que qu'un aura très bientôt (dans quelques heures) l'occasion de lire le code que vous êtes en train d'écrire en ce moment, vous y réfléchissez à deux fois avant de créer de la complexité que vous n'êtes pas en mesure de justifier. Kent Beck (XP)
50. Bienveillance et Respect
51. cadre et checklist
52. Formulation
53. 1 ou 2 relecteurs
54. Utile?  Lisibilité du code  Qualité/maintenabilité  Communication / transfert de comp.  Responsabilité collective du code  Uniformiser le code  Importance de la lisibilité pour le client ?  Qualité/maintenabilité peut être assurée par un outillage automatique  Coût en temps  Stress/tensions de la revue systématique  Craftmanship
55. Sprint 0