Revue de code et qualité continue

Prérequis : cours 1.1-1.2 (principes).

Pourquoi

La revue est le dernier filtre avant la prod — et le premier lieu d'apprentissage de l'équipe (solo : de ton futur toi). Mal faite, elle ralentit tout ; bien faite, elle diffuse les standards sans réunion.

Concepts

• Ce qu'on relit : correction, lisibilité, tests, perfs évidentes, sécu. Ce qu'on ne relit PAS : le style (linter), les goûts (formatter) — automatisés, jamais débattus.
• Taille : < 400 lignes, une intention par MR. Au-delà, on approuve sans lire (prouvé). Découper > supplier.
• Commentaires : question > ordre (« et si X était nul ? » plutôt que « mets un guard »), un compliment quand c'est mérité, et le fameux « LGTM rapide car trivial » assumé pour les petites.
• En solo : auto-revue différée (relire sa MR le lendemain avec des yeux frais attrape 30 % de bêtises), checklist personnelle, CI impitoyable (lint, tests, build — cf. DevOps 5.1).

Exemple : checklist solo (5 min)

[ ] Nomme-t-il ce qu'il fait ? (pas ce qu'il est)
[ ] Testé (dont le cas d'erreur) ?
[ ] Pas de secret, pas de TODO muet ?
[ ] Rollback possible (migrations compatibles) ?
[ ] Taille < 400 lignes, une intention ?

Cas réel

Bug prod par variable d'env mal nommée (STRIPE_KEY test en prod) : la checklist « pas de secret + diff des env » l'aurait attrapé en 10 secondes. Depuis : checklist + diff .env.example obligatoire en revue.

Pièges

• Nitpicks qui bloquent : les micro-détails en suggestion non bloquante, jamais en veto.
• « LGTM » en 30 secondes sur 2000 lignes : pire que pas de revue (fausse confiance). Découper ou assumer.
• Revue = QA : non. La revue attrape la conception, les tests attrapent les régressions. Les deux, pas l'un pour l'autre.

À retenir

Petites MR, style automatisé, questions pas ordres, checklist solo + CI impitoyable.