Culture de la revue de code et bonnes pratiques des PR

La revue de code n’est pas un contrôle d’accès : c’est un moyen pour les équipes d’apprendre ensemble, de transférer les responsabilités et de maintenir un haut niveau de qualité. Une bonne culture de revue fait progresser toute l’équipe ; une mauvaise crée des goulots d’étranglement et du ressentiment.

1) Gardez-la courte (moins de 400 lignes si possible). 2) Rédigez une description claire : pourquoi, quoi, comment la tester. 3) Ajoutez un lien vers la tâche. 4) Ajoutez des captures d’écran ou des vidéos pour les changements de l’interface utilisateur. 5) Relisez vous-même vos modifications avant de demander une revue.

Utilisez les mêmes préfixes conventionnels que pour les validations : feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. De nombreuses équipes génèrent leurs journaux de modifications à partir de ces préfixes.

La plupart des équipes utilisent un modèle de PR : installez-le dans .github/pull_request_template.md.

Avant de demander une revue, parcourez vos propres modifications ligne par ligne. Ajoutez des commentaires pour expliquer les choix qui ne vont pas de soi. Vous détecterez souvent vos propres erreurs avant que quelqu’un d’autre n’ait à le faire.

Une PR de 2 000 lignes est rarement relue attentivement. Divisez-la en : 1) une refactorisation (sans changement de comportement), 2) un nouveau comportement, 3) une amélioration de l’interface utilisateur. Chaque partie est plus facile à relire et à annuler.

Formulez vos remarques sous forme de questions, et non d’ordres : « Que pensez-vous d’extraire ceci dans une fonction réutilisable ? » vaut mieux que « extrayez ceci ». Distinguez les corrections indispensables des améliorations facultatives. Utilisez les préfixes suivants : nit:, question:, blocker:.

« C’est déroutant » n’apprend rien à l’auteur. « J’ai dû lire ceci trois fois pour comprendre le retour anticipé : pourrions-nous extraire une clause de garde ? » lui donne une piste concrète.

Faites des commentaires positifs sur les solutions astucieuses, les noms bien choisis et les tests utiles. Cela encourage ces pratiques et adoucit le reste de vos retours. Les PR qui ne reçoivent que des critiques donnent une impression de confrontation.

Prettier s’occupe de la mise en forme. ESLint s’occupe du style. Ne perdez pas de temps de revue sur les tabulations ou les espaces. Si une règle de style revient régulièrement, encodez-la dans l’outil d’analyse.

Les tests sont aussi du code. Assurez-vous que le nouveau code possède des tests. Vérifiez qu’ils testent réellement le bon élément : de nombreux tests réussissent même lorsque le code est défectueux, parce qu’ils vérifient le mauvais élément.

Répondez à chaque commentaire, même avec un simple emoji de pouce levé. N’hésitez pas à contester les suggestions avec lesquelles vous n’êtes pas d’accord (c’est vous qui avez écrit le code ; vous avez peut-être un contexte particulier). Marquez les fils traités comme résolus. Mettez à jour la description de la PR si son périmètre évolue.

Effectuez la revue dans un délai d’un jour ouvré. Les PR laissées à l’abandon perdent leur contexte : l’auteur est passé à autre chose et la branche doit être rebasée. Les grandes PR qui restent en attente pendant une semaine donnent toujours lieu à des fusions cauchemardesques.

La fonctionnalité de suggestions de GitHub permet à l’auteur d’accepter une correction en un clic. C’est bien plus rapide que d’écrire « remplacez cette ligne par X » en toutes lettres.

Approuvez lorsque : le code est correct, les tests réussissent, vous comprenez le changement et sa fusion ne présente pas de risque. Approuver signifie que vous assumez collectivement le résultat. N’approuvez pas machinalement : si vous n’avez pas lu le code, dites-le.

Auteur : des PR courtes et bien décrites, avec des captures d’écran et des tests. Commencez par vous relire. Relecteur : des retours constructifs formulés sous forme de questions. Distinguez les blocages des détails mineurs. Valorisez les bons choix. Ignorez le style : laissez les outils s’en charger. Effectuez la revue dans la journée. N’approuvez que lorsque vous comprenez le changement. Les modèles de PR standardisent le processus. Les revues sont une collaboration, pas un contrôle d’accès.