Ce que 3 ans de code reviews m'ont appris

Je pensais que les code reviews servaient à trouver des bugs.

J'avais tort.

En 3 ans, j'ai review des centaines de PRs. Mon code s'est fait démonter. J'ai écrit des commentaires que je regrette. J'ai approuvé des trucs que j'aurais pas dû. J'ai bloqué des trucs qui comptaient pas.

Voici ce que j'ai vraiment appris.

Leçon 1 : les meilleures reviews ne parlent pas de code

Le code n'est que l'artefact. Les vraies questions sont :

• Est-ce que ça résout le bon problème ?
• Est-ce qu'on va regretter ça dans 6 mois ?
• Est-ce que quelqu'un d'autre peut comprendre sans explication ?

Un jour j'ai approuvé une PR techniquement parfaite. Code propre, bons tests, types corrects. Trois mois plus tard, on l'a entièrement réécrite parce qu'elle résolvait le mauvais problème.

L'auteur avait mal compris les specs. Je n'avais jamais demandé "quel problème on résout ?" J'avais juste regardé le code.

Maintenant mon premier commentaire porte toujours sur l'intention, pas l'implémentation.

Leçon 2 : les petites PRs reçoivent de meilleures reviews

Les grosses PRs se font valider à l'aveugle. Je l'ai fait. Tu l'as fait.

500 lignes ? Je survole. Je rate des trucs. J'approuve parce que j'en ai marre de regarder.

50 lignes ? Je lis vraiment chaque ligne. Je réfléchis aux edge cases. Je suggère des améliorations.

Les études le confirment. La qualité des reviews chute drastiquement après 200-400 lignes. Ton cerveau abandonne.

J'ai commencé à rejeter les PRs trop grosses. Pas parce que le code était mauvais, mais parce que je ne pouvais pas les review correctement.

"Tu peux découper en plus petites PRs ?" est devenu mon commentaire le plus fréquent.

Leçon 3 : critique le code, pas la personne

Au début de ma carrière, j'écrivais des commentaires comme :

• "T'as pas géré le cas d'erreur"
• "T'as oublié d'ajouter des tests"
• "C'est faux"

Chaque commentaire commençait par "tu." Chaque commentaire ressemblait à une attaque.

Maintenant j'écris :

• "Qu'est-ce qui se passe si l'API renvoie une erreur ici ?"
• "Cette fonction pourrait bénéficier d'un test pour le edge case"
• "Je suis pas sûr de comprendre l'approche, tu peux m'expliquer ?"

Même feedback. Ton complètement différent.

La personne qui reçoit la review ne devrait pas se sentir sur la défensive. Elle devrait sentir qu'on résout un problème ensemble.

Leçon 4 : explique le pourquoi, pas juste le quoi

Mauvais commentaire :

"Utilise useMemo ici"

Meilleur commentaire :

"Ce calcul s'exécute à chaque render. Comme il est coûteux et que les dépendances changent rarement, useMemo pourrait améliorer les performances."

Le premier commentaire dit quoi faire. Le second enseigne quelque chose.

J'ai plus appris des reviewers qui expliquaient leur raisonnement que de n'importe quel tuto. Les code reviews sont du mentorat déguisé en contrôle qualité.

Quand je prends le temps d'expliquer pourquoi, l'auteur ne corrige pas juste cette PR. Il écrit du meilleur code dans la suivante.

Leçon 5 : tous les commentaires ne nécessitent pas d'action

Avant, je traitais chaque commentaire de review comme un bloquant. Mes PRs passaient par 5 rounds de changements avant approbation.

Puis j'ai découvert les préfixes :

• nit: Préférence de style mineure, libre à toi d'ignorer
• suggestion: Considère ceci, mais pas bloquant
• question: Je suis curieux, pas forcément une demande de changement
• blocker: Ça doit changer avant le merge

Exemple :

nit: J'appellerais ça userCount au lieu de count, mais c'est toi qui vois.

vs.

blocker: Cette requête n'a pas de pagination. Avec 100k utilisateurs, ça va timeout.

Tout n'est pas aussi important. Labellise tes commentaires pour que l'auteur sache ce qui compte vraiment.

Leçon 6 : approuve avec commentaires

Pendant des années, je pensais qu'il n'y avait que deux options : approuver ou demander des changements.

Puis j'ai appris "approuver avec commentaires."

"Approuvé ! Quelques suggestions mineures ci-dessous, mais rien de bloquant. Libre à toi de les traiter dans cette PR ou une prochaine."

Ça débloque l'auteur tout en partageant du feedback. Il peut merge maintenant et itérer, ou traiter les commentaires s'il a le temps.

J'utilise ça pour :

• Les nitpicks qui n'affectent pas la fonctionnalité
• Les suggestions d'amélioration future
• Les questions qui n'ont pas besoin de réponse avant le merge

Ça garde la vélocité haute sans sacrifier le feedback.

Leçon 7 : review ta propre PR d'abord

Avant de demander une review, je parcours mon propre diff. Ligne par ligne.

À chaque fois, je trouve des trucs :

• Des console.logs que j'ai oublié d'enlever
• Des commentaires qui n'ont pas de sens
• Des noms de variables que je peux améliorer
• Des edge cases que j'ai ratés

Si je peux trouver des problèmes dans mon propre code, pourquoi perdre le temps d'un reviewer ?

J'ajoute aussi des commentaires sur ma propre PR pour expliquer les décisions non évidentes :

"J'ai choisi de dupliquer ce code plutôt que d'abstraire parce que les deux cas d'usage pourraient diverger. Heureux de refactorer si tu n'es pas d'accord."

Ça donne du contexte aux reviewers et montre que j'ai réfléchi aux compromis.

Leçon 8 : le but c'est de livrer, pas la perfection

J'ai bloqué des PRs pour du formatage. Pour des noms de variables. Pour des préférences stylistiques.

C'était de l'ego, pas du contrôle qualité.

La vraie question est : est-ce que ce code est assez bon pour être livré ?

Assez bon signifie :

• Ça marche
• Ça n'introduit pas de bugs
• Ça ne crée pas de dette technique qu'on regrettera
• Quelqu'un d'autre peut le maintenir

Ça ne veut pas dire que c'est comme je l'aurais écrit. Ça ne veut pas dire que c'est la solution la plus élégante. Ça veut dire que c'est livrable.

J'ai appris à me demander : "Si ça part en prod tel quel, est-ce que quelque chose de grave va arriver ?" Si la réponse est non, approuve.

Leçon 9 : réponds vite, review en profondeur

Une PR qui attend 3 jours tue le momentum. L'auteur change de contexte. Le code devient stale. Les conflits de merge apparaissent.

J'essaie de répondre aux PRs en quelques heures. Même si c'est juste :

"Je review ça correctement demain, mais je voulais te dire que j'ai vu."

La vitesse compte. Mais la vitesse sans qualité c'est pire que la lenteur.

Quand je review, je prends le temps de bien faire. Je ne survole pas. Je checkout la branche. Je lance le code. Je réfléchis aux edge cases.

Accusé de réception rapide + review approfondie > lenteur partout.

Leçon 10 : recevoir des reviews est aussi une compétence

Se faire critiquer son code, c'est dur. Je me suis senti sur la défensive. J'ai argumenté sur des commentaires. J'ai pris le feedback personnellement.

Maintenant j'aborde les reviews différemment :

• Présume la bonne intention. Le reviewer essaie d'aider, pas d'attaquer.
• Pose des questions de clarification. Si je ne comprends pas un commentaire, je demande.
• Dis merci. Quelqu'un a passé du temps à améliorer mon code.
• Sois en désaccord respectueusement. "Je vois ton point, mais voilà pourquoi j'ai choisi cette approche..."

Les meilleurs ingénieurs avec qui j'ai travaillé acceptent le feedback avec grâce. Ils n'argumentent pas, ils discutent. Ils ne défendent pas, ils expliquent.

Les code reviews sont une conversation, pas un jugement.

La cheat sheet

La leçon

Les code reviews ne servent pas à prouver que t'es intelligent. Elles servent à améliorer le code et renforcer l'équipe.

Les meilleurs reviewers que je connais sont généreux avec leurs connaissances et doux avec leur feedback. Ils te donnent envie d'écrire du meilleur code, pas de redouter leurs commentaires.

C'est ce que j'apprends encore à devenir.

C'est la partie 4 de ma série "Ce que j'ai appris à mes dépens". Prochain article : ce que j'aurais aimé savoir avant de lancer mon premier SaaS.

Des questions ? Contacte-moi sur LinkedIn ou découvre plus sur mon blog.