Introduction aux revues de code

Powerpoint de ma présentation à l'Agile Tour Pays-Basque

Transcript

1. Confidentiel Personnalisé pour Nom de l'entreprise Version 1.0 Introduction aux revues de code Comment s’assurer que ça ne sert pas à rien
2. Docteur Code, j’ai mal ! On trouve des régressions en prod On a du mal à faire monter en compétence les développeurs Les fonctionnalités ne sont même pas correctement implémentées Les perfs s’écroulent à cause d’une jointure foireuse La qualité du code diminue
3. La revue de code c’est quoi ?
4. Quand faire de la revue de code ? Après que le code soit écrit, duh !
5. La revue de code c’est avant tout un feedback
6. Les différents types/format de feedback Asynchrone Synchrone Solitaire Toute l’équipe Pair Programming IDE + compilation Mob Programming Static Code Analysis (Sonar) Branche abandonnée avant les vacances Pair Review of code Mob Review of code
7. Retour d’expérience, on envoie des satellites en l’air
8. Si la revue de code prend 20 minutes, c’est qu’elle est mal faite
9. J’aurais du demander du feedback plus vite pour éviter de perdre du temps
10. Deux semaines de code à relire, c’est trop long
11. Les fausses bonnes idées de la revue de code •  Utiliser un outil •  Avoir une équipe en charge des revues de code •  Systématiquement avoir un expert relire le code des débutants •  Réécrire le code des débutants quand ça va pas
12. De quoi ne doit-on pas parler en revue de code ? Indentation Organisation des imports “J’aime pas les boucles utilise plutôt des streams” “Vavr ça pue la mort” “J’aime pas trop le design pattern Singleton, vire ça”
13. Mais du coup on regarde quoi dans une revue de code ? •  Conformité au standard de code de l’équipe •  Qualité/expressivité (présence ?) des tests unitaires •  Qualité du nommage •  Design de l’application •  Performances •  Est-ce que le code fait bien ce qu’il doit faire
14. Niveau temporalité On prend le temps de bien faire, une revue superficielle est inutile Une revue de story devrait prendre entre 10 et 25% du temps de développement Essayer de se limiter à 300 LoC (code + test)
15. Comment on donne le feedback 1.  On discute tous les deux derrière un écran plutôt qu’un mail 2.  On est dur avec le code, doux avec les gens 3.  Egoless programming
16. Qui corrige ? 1.  On corrige en binôme 2.  L’auteur du code
17. Maintenant, comment on fait ? AT-Pays Basque Mob Review -> standards de code de l’équipe On commence les revues
18. Commencer les revues de code Pair-programming : 1 fois par jour •  Débuter une user- story •  Code Legacy •  Débug •  Code complexe Revue de code : Tout le temps Mob programming : 1 fois par sprint Nouvelle technologie Standards de code Code critique
19. Merci !