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
   

   View Slide

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
   

   View Slide

3. La revue de code
   c’est quoi ?
   

   View Slide

4. Quand faire de la revue de code ?
   Après que le code soit écrit, duh !
   

   View Slide

5. La revue de code c’est avant tout un feedback
   

   View Slide

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
   

   View Slide

7. Retour d’expérience, on envoie des satellites
   en l’air
   

   View Slide

8. Si la revue de code prend 20 minutes, c’est
   qu’elle est mal faite
   

   View Slide

9. J’aurais du
   demander du
   feedback plus
   vite pour éviter
   de perdre du
   temps
   

   View Slide

10. Deux semaines
    de code à
    relire, c’est
    trop long
    

    View Slide

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
    

    View Slide

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”
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

16. Qui corrige ?
    1.  On corrige en binôme
    2.  L’auteur du code
    

    View Slide

17. Maintenant, comment on fait ?
    AT-Pays Basque
    Mob Review ->
    standards de code
    de l’équipe
    On commence
    les revues
    

    View Slide

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
    

    View Slide

19. Merci !
    

    View Slide