Save 37% off PRO during our Black Friday Sale! »

Introduction aux revues de code

Introduction aux revues de code

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

E45fd7ac29c74ef0c25965b08e5024a3?s=128

Fabien Lamarque

September 21, 2018
Tweet

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 !