Code Review — qu'est-ce que c'est, comment fonctionne la revue de code et la vérification des PR

Qu'est-ce que le Code Review

Code review est une vérification systématique du code par des collègues avant intégration. Dans le contexte de Git, cela signifie : un développeur crée une pull request avec des modifications, désigne des relecteurs, et ceux-ci étudient le diff, laissent des commentaires et rendent un verdict. Un relecteur peut demander des modifications, approuver le PR ou laisser un commentaire général.

La revue de code poursuit cinq objectifs : améliorer la qualité du code (trouver des défauts avant qu'ils n'atteignent la production), diffuser les connaissances (le relecteur découvre de nouvelles approches, l'auteur reçoit des retours), garantir les normes (vérifier la conformité au style de code et aux décisions architecturales), réduire le bus factor (plus d'un développeur connaît le code) et construire une culture de responsabilité (l'auteur écrit plus soigneusement en sachant que le code sera revu).

L'opposé de la revue de code est un blind commit : un développeur pousse des modifications dans une branche partagée sans revue. Cette approche n'est acceptable que dans les projets mono-développeur ou pour les correctifs urgents avec revue ultérieure. Dans le développement professionnel en équipe, la revue de code est une étape obligatoire pour toute modification, y compris les mises à jour de documentation et de configuration.

Que vérifier dans le Code Review

La revue de code doit être systématique, pas chaotique. Les relecteurs expérimentés vérifient le code dans un ordre spécifique : d'abord l'architecture et la logique, puis les tests, ensuite la sécurité et les performances, et seulement à la fin — le style et le nommage. Cet ordre garantit que les problèmes critiques sont remarqués avant que le relecteur ne se fatigue.

Architecture et logique : le code résout-il la tâche, y a-t-il des abstractions excessives, les principes SOLID et DRY sont-ils respectés ? Un code complexe difficile à comprendre à la première lecture est un signe qu'un refactoring est nécessaire. Le relecteur doit s'assurer que le code fait exactement ce que la tâche spécifie et n'a pas d'effets secondaires au-delà de sa responsabilité.

Tests : les nouveaux tests couvrent-ils tous les scénarios — positifs, négatifs, cas limites. Les tests existants passent-ils après les modifications ? Y a-t-il des tests instables qui échouent de manière inconsistante ? Sécurité : absence d'injections SQL, XSS, fuites de données sensibles via les logs ou les réponses API. Performances : efficacité des algorithmes, requêtes excessives à la base de données, fuites de ressources.

• Architecture — exactitude de la solution, conformité SOLID, absence de sur-ingénierie.
• Logique — traitement de tous les scénarios, y compris les erreurs et les cas limites.
• Tests — couverture des nouvelles modifications, aucun test existant cassé.
• Sécurité — injections, XSS, CSRF, fuites de données via les logs.
• Performances — complexité des algorithmes, requêtes N+1, fuites mémoire.

Taille de la revue : pourquoi 400 lignes est le maximum

La limite de taille du PR est la métrique la plus importante de l'efficacité de la revue de code. Une étude de Cisco (2015) et les expériences ultérieures de SmartBear et Google ont montré que lorsque le volume de la revue dépasse 400 lignes, la capacité du relecteur à trouver des défauts chute drastiquement. Si un PR dépasse 400 lignes, les défauts sont détectés avec une probabilité non supérieure au hasard.

Taille optimale : 200–400 lignes par PR. Ce volume peut être revu en 30–60 minutes en maintenant la concentration. Google recommande pas plus de 200 lignes par tour de revue avec une concentration totale. Si les modifications sont plus importantes, la tâche doit être décomposée en plusieurs PR séquentiels, chacun introduisant un changement logiquement complet.

Temps de revue : dans les 24 heures suivant la création du PR. Si la revue s'éternise sur plusieurs jours, le contexte de la tâche est perdu, et l'auteur doit passer du temps à restaurer le contexte en répondant aux commentaires. Les équipes avec une forte culture de revue de code établissent des SLA : par exemple, 4 heures pour les modifications critiques et 24 heures pour les modifications régulières.

Comment rédiger de bons commentaires de revue

Le ton des commentaires est crucial pour l'efficacité de la revue de code. Un commentaire comme « C'est faux » provoque une réaction défensive et ne fournit pas d'informations utiles à l'auteur. Une meilleure formulation est une question-suggestion : « Que pensez-vous de cette approche ? », « Cela pourrait provoquer une NPE si user == nil. Peut-être ajouter un guard ? ». Les questions sont moins conflictuelles et stimulent la discussion.

Un bon commentaire comprend trois parties : ce qui ne va pas, pourquoi c'est un problème et comment le corriger. Exemple : « Cette boucle utilise O(n²) à cause d'un contains imbriqué, ce qui pourrait ralentir avec 10k+ enregistrements. Essayez de remplacer par un Set pour une recherche en O(1). » Cette formulation identifie simultanément le problème, explique son importance et suggère une solution — l'auteur n'a pas à deviner.

GitHub et GitLab prennent en charge les suggestions — des propositions de modification de code en ligne. Un relecteur peut écrire : « ```suggestion Filter empty strings before processing``` » et l'auteur peut appliquer la modification en un clic. Cela accélère les petites corrections et réduit le nombre de tours de revue. Pour les modifications importantes, il est préférable d'écrire un commentaire général plutôt que d'incorporer de gros blocs dans une suggestion.

# Modèle de bon commentaire de code review

# MAUVAIS : "This code is wrong"
# BON : "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Syntaxe de suggestion GitHub :
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow de Code Review en équipe

Un workflow de revue efficace repose sur quatre étapes. Première — l'auteur prépare le PR : écrit un titre clair (par exemple, « feat: add password reset screen »), ajoute une description des modifications, des liens vers la tâche dans le tracker et des instructions de test. Deuxième — l'auteur désigne des relecteurs via auto-assign (basé sur CODEOWNERS) ou manuellement.

La troisième étape — le relecteur vérifie le code et laisse des commentaires. La quatrième — l'auteur effectue les corrections, répond aux commentaires et demande une re-revue. Le cycle se répète jusqu'à l'obtention de l'approbation. Après approbation, l'auteur effectue la fusion (ou le bot le fait). L'automatisation via Mergify ou GitHub Auto-merge accélère l'étape finale.

Un élément important du workflow est la gestion des PR obsolètes. Si un PR reste sans revue pendant plus de 3 jours, le processus est bloqué. Solutions : rotation des relecteurs (si le relecteur désigné est indisponible), notifications via Slack/Teams, limite de temps pour la revue (SLA). Dans certaines équipes, un PR sans revue depuis plus de 7 jours est automatiquement fermé, et l'auteur en crée un nouveau après synchronisation avec main.

• Création du PR — titre clair, description, liens de tâche, captures d'écran pour les modifications UI.
• Désignation — auto-désignation via CODEOWNERS ou sélection manuelle de 1–2 relecteurs.
• Revue — vérification dans l'ordre : architecture → logique → tests → sécurité → style.
• Corrections — l'auteur répond à tous les commentaires, corrige les problèmes bloquants, demande une re-revue.
• Fusion — après approbation et CI vert, l'auteur ou le bot effectue la fusion.

Erreurs courantes de Code Review

La première erreur — revue superficielle. Le relecteur scanne rapidement le diff sans approfondir la logique et clique sur Approuver. Causes : PR volumineux, délai, fatigue. Conséquences : les bogues atteignent la production. Solution : si vous n'avez pas le temps pour une revue de qualité — écrivez honnêtement « Je ne peux pas revoir aujourd'hui, reportez à demain » au lieu d'une approbation formelle.

La deuxième erreur — critique excessive (nitpicking). Le relecteur laisse des dizaines de commentaires sur le style de formatage, le nommage des variables, des détails triviaux. Cela démotivie l'auteur et prolonge la revue. Solution : le guide de style et les linters doivent vérifier le style automatiquement. L'humain dans la revue vérifie la logique, l'architecture et la sécurité.

La troisième erreur — revue sans questions. Si le relecteur ne publie que des Request Changes et Approve mais ne pose pas de questions, il rate l'occasion d'apprendre quelque chose de nouveau. Le meilleur indicateur d'une revue saine est la présence de discussions dans lesquelles les deux parties apprennent quelque chose de nouveau. Si une revue est un monologue d'un participant, le processus est cassé.

• Revue superficielle — Approbation sans analyse approfondie. Solution : ne pas revoir si vous n'avez pas le temps.
• Nitpicking — critiquer le style qui devrait être vérifié par un linter. Solution : automatiser les vérifications de style.
• Préférence personnelle — « J'aurais écrit différemment ». Solution : le code doit fonctionner, pas plaire au relecteur.
• Retard — revue de plus de 24 heures. Solution : SLA sur la revue, escalade en cas de violation.
• Ignorer le contexte — revoir le code sans comprendre la tâche. Solution : lire la description du PR avant le diff.