Tech lead : faire des code reviews qui font grandir l'équipe

En tant que tech lead, j'ai accompagné plusieurs développeurs, du junior au confirmé. De tous les outils à ma disposition (pair programming, ateliers, documentation), la code review est celui qui a eu le plus d'impact. À condition de la faire bien : une review mal menée ralentit l'équipe, frustre les auteurs et ne détecte même pas les vrais problèmes.

À quoi sert vraiment une code review ?

• Partager la connaissance : au moins deux personnes connaissent chaque partie du code.
• Aligner les pratiques : conventions, architecture, patterns maison.
• Détecter les problèmes de conception tant qu'ils sont encore peu coûteux à corriger.
• Et, accessoirement, trouver des bugs. Accessoirement, car les tests et les outils automatiques le font mieux.

La pyramide de la code review

Un modèle m'aide à prioriser : la pyramide de la code review, popularisée par Gunnar Morling. Plus un point est bas dans la pyramide, plus il est facile à automatiser et moins il mérite l'attention humaine. Plus il est haut, plus il est coûteux à changer après la fusion.

• Style et formatage : Prettier et ESLint. Un humain ne devrait jamais commenter une indentation.
• Tests : les cas importants sont-ils couverts ? Les tests vérifient-ils le comportement ou l'implémentation ?
• Documentation : les décisions non évidentes sont-elles expliquées ?
• Implémentation : lisibilité, gestion des erreurs, performance, sécurité.
• Conception de l'API et du modèle de données : c'est là que se trouvent les décisions les plus difficiles à défaire. C'est là que la review a le plus de valeur.

Comment formuler les commentaires

La forme compte autant que le fond. Quelques règles que j'applique :

• Questionner plutôt qu'affirmer : « Que se passe-t-il si la liste est vide ? » invite à réfléchir, « C'est faux » ferme la discussion.
• Expliquer le pourquoi : un lien vers la documentation ou une phrase de contexte transforme une correction en apprentissage.
• Distinguer le bloquant du facultatif : je préfixe mes commentaires. bloquant: pour ce qui doit changer, suggestion: ou nit: pour le reste. L'auteur sait où concentrer son énergie.
• Relever aussi ce qui est bien fait : un « bonne idée cette extraction » renforce les bonnes pratiques bien plus qu'on ne le pense.
• Passer à l'oral au-delà de trois allers-retours : dix minutes d'appel valent mieux qu'un fil de quarante commentaires.

Côté auteur : faciliter la review

• Des pull requests petites : au-delà de 400 lignes, l'attention chute fortement. Découpez : refactoring préparatoire d'un côté, fonctionnalité de l'autre.
• Une description utile : quel problème, quelle solution, comment tester, captures d'écran pour l'interface.
• Une auto-review avant de demander : relire son propre diff attrape une bonne partie des oublis.

Éviter le goulot d'étranglement

Le tech lead ne doit pas être le relecteur obligatoire de chaque pull request. Sinon, l'équipe attend, et personne d'autre n'apprend à relire.

• Un objectif de délai : une première réponse dans la demi-journée.
• Des relecteurs tournants, y compris les juniors : relire le code des autres est l'un des meilleurs moyens d'apprendre.
• Des règles écrites : un guide de review partagé évite que chaque relecteur ait ses propres exigences.

Conclusion

Une bonne code review ne se mesure pas au nombre de commentaires, mais à ce que l'équipe a appris et au fait que le code fusionné est compris par plus d'une personne. Automatisez la base de la pyramide, concentrez-vous sur la conception, et formulez chaque commentaire comme si vous parliez à quelqu'un que vous voulez voir progresser.