La revue de code 2.0

Depuis l'époque des revues de code ponctuelles avec retours partagés en réunion ou dans un tableau excel les usages ont bien changé: revues systématiques du code sans échanges en face à face avec le développeur (via les merge requests, pull requests ou requête de tirage). Ces nouveaux usages ont des avantages mais aussi des inconvénients et sont souvent mal utilisés, mal vécus voire générateurs de conflits. En apprenant de ces erreurs, peut-on réinventer la revue de code et passer à la version 3.0 ?

Transcript

2. Sandrine Banas @Cosjava 20 ans
8. La revue de code
10. Lisibilité du code Améliorations syntaxiques Oubli d’implémentation Bug, défaut de conception Communiquer son état d’avancement Transfert de connaissances Accompagnement d’un junior Responsabilité collective du code
11. Les alertes
12. Les MR bloquent plus de 24h
13. Les MR bloquent plus de 24h Mettre les MR en visibilité Temps d’attente d’une pull/merge request pour être relue
15. Certaines MR ne sont pas relues
16. Certaines MR ne sont pas relues Plus d’attractivité Mise en confiance des juniors Temps selon langage / taille des MR
17. La même personne lit toutes les MR
18. La même personne lit toutes les MR Rappel des règles Nombre de MR par relecteur
19. Auto-merge
21. Copinage
22. Auto-merge / copinage Rappel des règles Développeur vs relecteur
23. Des échanges sans fin sur une MR
24. Des échanges sans fin sur une MR Règle sur la validation et échange de vive voix Nombre de MR dépassant un nv usuel de discussions
25. Les modifications en douce post-MR
26. Des MR temporairement fermées
27. Les modifications en douce post-MR Respect et bienveillance Des MR temporairement fermées
28. Des réactions émotionnelles attaque / fuite / repli sur soi
29. Des réactions émotionnelles Communication non violente
30. Les problèmes de fusion
32. La partie cachée d’une Revue de code
35. La critique est aisée, et l’art est difficile. Philippe Néricault
36. Egoless programming Que peut-on faire à propos du problème de l’ego dans la programmation ?
37. Traiter les gens qui en savent moins que vous avec respect, déférence et patience
38. Comprendre et accepter que vous ferez des erreurs
39. Critiquer le code plutôt que les personnes. Soyez bienveillant pour le codeur pas pour le code.
40. Vous n’êtes pas votre code.
41. 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
42. 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
43. Bonnes pratiques Pour le codeur
44. Etat d’esprit Résilience et Gratitude Entretenir le désir d’apprendre Développement vs fixe (Carol Dweck) Kaizen
47. La responsabilité collective du code a de toute façon tendance à éviter que du code compliqué soit ajouté au système. Kent Beck (XP)
48. 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)
49. Petite 250 lignes
50. Single Responsability Principle 1
51. Titre clair Etiquettes
52. Formatage
53. Bonnes pratiques Pour le relecteur
54. Etat d’esprit Cultiver l’empathie, la gratitude et la curiosité
55. Bienveillance et Respect
56. cadre et checklist
57. Formulation
58. Retours positifs
59. 1 ou 2 relecteurs
60. 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
61. Sprint 0
62. La qualité avant l’humain  Ressenti comme manque de confiance  Stress de l’imposé  Apprentissage forcé  Le bien-être de l’équipe en premier lieu Valoriser les experts  Soutenir les juniors  Volontariat / confiance  Des revues de code de vive-voix  Revues automatisées  Walkthrough review