Revue de Code : Règles Simples pour Éviter les Guerres d’Ego

La revue de code est un des meilleurs outils pour améliorer la qualité, partager la connaissance et éviter les bugs. Pourtant, elle peut rapidement dégénérer en champ de bataille où les egos s’entrechoquent, où les commentaires deviennent personnels et où l’objectif principal – avoir un meilleur code – est perdu de vue. Comment transformer ce processus potentiellement conflictuel en une collaboration productive et bienveillante ? Voici des règles simples, centrées sur l’humain, pour des revues de code efficaces et sans drama.

Règle Fondamentale : Critiquez le Code, Pas la Personne

C’est la première loi, absolue et non négociable. Le code est un artefact produit par une personne, mais il n’est pas cette personne.

• À proscrire à tout prix : « Pourquoi tu as écrit ça comme ça ? C’est n’importe quoi. », « T’es vraiment nul en algorithmes. »

• À dire à la place : « Je ne suis pas sûr de comprendre la logique ici. Pourrais-tu expliquer pourquoi cette approche a été choisie ? », « Cette fonction est devenue assez complexe. Penses-tu qu’on pourrait l’extraire pour la rendre plus testable ? »

Astuce : Utilisez le « Je » et parlez de votre expérience de lecture. « Je me suis perdu à cette ligne », « Je crains que cette condition ne couvre pas le cas X ». Cela centre le propos sur l’effet du code, non sur l’intention supposée de son auteur.

Règle #1 : Posez des Questions, N’imposez pas des Solutions

Un relecteur n’est pas là pour réécrire le code à sa guise. Il est là pour poser des questions qui amèneront l’auteur à réfléchir et potentiellement s’améliorer lui-même.

• Approche directive (génératrice de conflit) : « Change ça, utilise plutôt un map ici. »

• Approche par question (collaborative) : « As-tu considéré l’utilisation d’un map pour cette transformation ? Je me demande si ça ne rendrait pas l’intention plus claire. » ou même « Quelle était l’intention derrière cette boucle for ? »

Le bénéfice : L’auteur reste maître de son code. Il peut expliquer son raisonnement (ce qui vous apprend peut-être quelque chose) ou réaliser par lui-même qu’il y a une meilleure façon. Cela favorise l’apprentissage plutôt que la soumission. Cliquez ici pour obtenir des informations supplémentaires.

Règle #2 : Fournissez du Contexte et des Références (Pas des Opinions)

Un commentaire basé sur une préférence personnelle (« Je n’aime pas les ternaires ») est inutile et irritant. Un commentaire basé sur une règle partagée ou une bonne pratique objective est constructif.

• Commentaire subjectif : « C’est moche. »

• Commentaire objectif et utile : « Le nom de cette variable (data) est très générique. En la renommant formattedReport (par exemple), le code serait plus explicite. » ou « Le guide de style de l’équipe recommande de gérer les erreurs asynchrones avec try/catch dans ce contexte, plutôt qu’avec .catch(). »

L’arme secrète : Liez vers la documentation de l’équipe, une RFC interne, ou un article externe (ex: « Le Principe de Responsabilité Unique ») pour étayer votre suggestion. Cela dépersonnalise complètement le feedback.

Règle #3 : Célébrez ce qui est Bien ! (Le Feedback Positif)

Une revue de code n’est pas une chasse aux erreurs. C’est aussi l’occasion de renforcer les bonnes pratiques et de motiver les collègues.

• Commentez quand vous voyez une solution élégante, un bon test, un nom de variable parfaitement clair.

• Dites « J’adore la façon dont tu as extrait cette logique, c’est super lisible ! » ou « Bonne idée d’avoir pensé à ce cas limite dans le test. »

Pourquoi c’est crucial ? Cela crée un climat de confiance. L’auteur sait que vous n’êtes pas là pour le descendre, mais pour l’aider à réussir. Il sera beaucoup plus réceptif à vos critiques constructives ensuite.

Règle #4 : Pour l’Auteur – Désarmez Votre Égo, Vous n’Êtes pas Votre Code

Cette règle est tout aussi importante pour celui qui reçoit les commentaires. Votre code a été critiqué ? Respirez. Ce n’est pas une attaque contre vous.

• Ne le prenez pas personnellement. Rappelez-vous que l’objectif est la qualité du projet collectif.

• Partez du principe que l’intention est bonne. Le relecteur veut aider, même si sa formulation est maladroite.

• Clarifiez, ne défendez pas. Si un commentaire semble basé sur une méprise, expliquez votre raisonnement avec calme : « J’ai choisi cette approche parce que… ». Cela peut être un simple malentendu.

• Vous n’êtes pas obligé de tout accepter. Si, après discussion, vous pensez que votre approche est valable, expliquez-le poliment. Une revue est une discussion, pas une dictature.

Règle #5 : Tenez la Discussion en Public, mais Résolvez en Privé si Nécessaire

Les commentaires doivent rester sur la plateforme de revue (GitHub, GitLab, etc.) pour la transparence et l’apprentissage collectif.

• Cependant, si un désaccord dégénère en débat technique pointu de 20 messages qui pollue le thread, ou si les émotions montent, proposez d’aller en discuter en visio ou devant un tableau blanc.

• « Je vois qu’on a des points de vue différents sur ce point. Ça te dirait qu’on en parle rapidement en call pour qu’on puisse dessiner les alternatives ? »

• Revenez ensuite sur la plateforme pour résumer la décision prise. Cela maintient la transparence sans l’asphyxie.

Une Checklist pour une Revue Sereine

En tant que relecteur :

• Ai-je formulé mon commentaire comme une question ou une suggestion basée sur une règle ?

• Ai-je critiqué le code et non la personne ?

• Ai-je salué au moins un point positif ?

• Mon commentaire vise-t-il à améliorer le code ou à imposer mon style ?

En tant qu’auteur :

• Est-ce que je considère les commentaires comme une aide et non une attaque ?

• Est-ce que je remercie mes relecteurs pour leur temps ?

• Est-ce que je clarifie au lieu de me justifier ?

La Revue de Code, Exercice d’Humilité Collective

Au fond, une bonne revue de code est un exercice d’humilité. Pour le relecteur : humilité de reconnaître qu’il existe plusieurs façons valables de résoudre un problème. Pour l’auteur : humilité d’accepter que son code puisse être amélioré.

En adoptant ces règles simples, vous ne supprimez pas les désaccords techniques – ils sont sains – mais vous supprimez le poison émotionnel qui les rend toxiques. Vous transformez la revue de code en un rituel d’apprentissage mutuel et de soin collectif du codebase, où l’ego reste à la porte et où la qualité du logiciel sort gagnante. Le meilleur code est presque toujours le fruit d’une bonne collaboration, pas d’un génie solitaire.