Présentationpar DevBlog9 diapositives
Revue de code efficace
Que relire, comment formuler ses commentaires et comment garder des revues rapides et bienveillantes.
- #revue-de-code
- #equipe
- #presentation
Revue de code efficace
On relit le code, pas la personne.
Pourquoi relire ?
- Détecter les bugs avant la production
- Partager la connaissance du code
- Garder une base cohérente
- Apprendre, dans les deux sens
Avant d'ouvrir la PR (auteur)
- Une PR = un sujet
- Petite : idéalement moins de 400 lignes
- Description claire : quoi, pourquoi, comment tester
npm run checkau vert
Que regarder ?
| Priorité | Question |
|---|---|
| 1 | Est-ce correct ? |
| 2 | Est-ce sûr ? (entrées, secrets, droits) |
| 3 | Est-ce testé ? |
| 4 | Est-ce lisible ? |
| 5 | Est-ce cohérent avec le reste ? |
Le style se confie au linter, pas aux humains.
Bien formuler un commentaire
❌ Ce code est mauvais.
❌ Pourquoi t'as fait ça ?
✅ Cette boucle est en O(n²) ; une Map ramènerait à O(n).
Qu'en penses-tu ?Décrivez le problème et proposez une piste.
Qualifier ses remarques
- Bloquant : doit être corrigé avant la fusion
- Suggestion : à la discrétion de l'auteur
- Question : j'essaie de comprendre
- Détail (nit) : mineur
Chacun sait ce qui est attendu.
Recevoir une revue
- Un commentaire vise le code, pas vous
- Répondez à chacun, même par « fait »
- En cas de désaccord, argumentez, ou appelez
Délais
Une PR en attente bloque quelqu'un.
- Premier retour sous un jour ouvré
- Revues courtes et fréquentes plutôt que rares et lourdes
À retenir
- Petites PR, bonnes descriptions
- Correct et sûr avant joli
- Bienveillance et clarté
1 / 9
Flèches ← → pour naviguer · F pour le plein écran