Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction aux revues de code

Introduction aux revues de code

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

Fabien Lamarque

September 21, 2018
Tweet

More Decks by Fabien Lamarque

Other Decks in Programming

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 full-size 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 full-size slide

  3. La revue de code
    c’est quoi ?

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide