Code review¶

Mener des reviews efficaces avec un feedback constructif qui fait progresser l'équipe.

La review n'est pas un filtre, c'est un outil¶

Une idée reçue : la code review sert à "empêcher les mauvais commits de passer". C'est une vision defensive qui produit des reviews anxiogenes et des reviewers bottlenecks.

La vision efficace : la review est un moment de partage de connaissance bilateral. Le reviewer apprend le contexte du contributeur ; le contributeur apprend d'une autre perspective sur son code.

Objectifs d'une review¶

1. Partage de connaissance — tout le monde comprend ce qui change et pourquoi
2. Qualité collective — deux paires d'yeux captent plus qu'une
3. Cohérence — le code reste lisible par l'ensemble de l'équipe
4. Sécurité — les patterns dangereux sont identifiés avant la production

Ce qui n'est pas l'objectif : prouver que le reviewer est plus intelligent, bloquer des changements par préférence stylistique, remplacer les tests.

Checklist de review¶

Utilisez cette grille pour structurer votre lecture, pas pour tout cocher mecaniquement.

Lisibilite¶

• Les noms de variables, fonctions et classes sont expressifs
• Le code se lit sans commentaires explicatifs superflus
• Les commentaires presents expliquent le "pourquoi", pas le "quoi"
• Les fonctions ont une seule responsabilité

Correction¶

• La logique correspond à la description de la MR
• Les cas limites (null, vide, overflow, concurrence) sont gérés
• Les tests couvrent les scenarios décrits dans la MR
• Les tests échouent si on retire le code qu'ils testent (pas de faux positifs)

Design¶

• Le code suit les patterns établis dans la base existante
• Aucune abstraction prematuree, aucune complexité inutile
• Les dépendances externes sont justifiees

Sécurité¶

• Pas d'injection possible (SQL, shell, HTML)
• Les secrets ne sont pas hardcodes
• Les entrees utilisateur sont validees
• Les permissions sont verifiees au bon endroit

Tests¶

• Les tests sont lisibles et maintenables
• Les cas de régression sont couverts
• Pas de tests qui testent l'implémentation plutôt que le comportement

Feedback constructif¶

Le principe NVC applique aux reviews¶

Separez l'observation du jugement :

Niveaux de sévérité dans les commentaires¶

Rendez explicite ce que vous attendez :

• nit: — suggestion stylistique, non bloquante ("nit: tu peux raccourcir avec une comprehension")
• suggestion: — amélioration, pas obligatoire ("suggestion: un dataclass serait plus expressif ici")
• question: — besoin de contexte ("question: pourquoi ce timeout a 30s plutôt que la valeur globale ?")
• blocker: — doit être corrige avant merge ("blocker: cette requête SQL est vulnerable à l'injection")

Review asynchrone vs synchrone¶

Taille des MR¶

La taille d'une MR est le facteur numéro 1 de la qualité d'une review.

graph LR
    A["MR > 500 lignes"] --> B["Reviewer fatigue"]
    B --> C["Review superficielle"]
    C --> D["Bugs passes en prod"]

    E["MR < 200 lignes"] --> F["Review focalisee"]
    F --> G["Feedback precis"]
    G --> H["Merge rapide"]

Règles pratiques¶

• Visez des MR de 50 a 200 lignes modifiées (hors code généré)
• Une MR = un objectif (feature, bugfix, refacto — pas les trois)
• Si une MR est grande, decomposez-la en étapes avec des MR intermédiaires sur une branche de feature

Focus par type de changement¶

Côté contributeur : préparer sa MR¶

Une bonne review commence avant que le reviewer ouvre la MR.

• Description claire : quel problème, quelle solution, comment tester
• Screenshots ou logs si pertinent
• Points d'attention : signaler ce qui est volontairement différent des conventions
• Self-review : relisez votre propre diff avant de demander une review

Points clés¶

• La review est un outil de partage, pas un filtre qualité solitaire
• Prefixez vos commentaires pour signaler leur sévérité
• Approuver avec commentaires non bloquants accéléré les livraisons
• Decomposez les grosses MR — la taille est l'ennemi de la review
• La self-review est la première étape obligatoire

Précédent : Fondamentaux | Suite : Pair et Mob programming