17 February 20267 min de lecture
Dans une mission distribuée, la revue de code n’est pas une barrière qualité qui intervient après le management. C’est le management. C’est là que les standards se transmettent, là que les malentendus apparaissent tant qu’ils sont encore bon marché, et là que vous découvrez si la personne recrutée sait vraiment faire le travail.
C’est pourquoi il vaut la peine de la traiter comme un processus conçu plutôt que comme quelque chose qui arrive quand les gens y pensent. L’essentiel des frictions décrites comme « l’équipe externalisée est lente » se révèle, à l’examen, être une file d’attente que les propres ingénieurs du client ne vident pas.
C’est la file d’attente le problème, pas le relecteur
Un travail qui attend en revue est un travail terminé qui ne produit rien. Pire, son auteur est passé à autre chose : quand la revue finit par arriver, il doit recharger tout le contexte. Un changement relu en quelques heures coûte cinq minutes à son auteur pour le traiter. Le même changement relu quatre jours plus tard lui coûte une heure, et le deuxième changement empilé par-dessus doit maintenant être rebasé.
Mesurez l’attente, pas le nombre de commentaires. Si vous ne suivez qu’une chose au sujet de la revue, suivez le temps qu’une pull request reste en attente avant qu’un humain ne la regarde. Ce chiffre est la mesure honnête de la qualité du pilotage de la mission, et c’est presque toujours le côté client qui le dégrade.
C’est là que la journée de travail partagée fait la preuve de son utilité. Quand vos relecteurs et l’auteur sont éveillés en même temps la majeure partie de la journée, une revue le jour même est une attente ordinaire plutôt qu’une ambition. Sur un écart de huit ou neuf heures, c’est structurellement impossible, et tout ce qui précède s’aggrave.
Les petites pull requests sont un outil de management
Un changement de quatre cents lignes reçoit une revue qui dit « ça me va ». Un changement de quarante lignes reçoit une revue qui trouve le bug. Ce n’est pas une question de sérieux : c’est une question de ce qu’un humain peut garder en tête.
Avec quelqu’un de nouveau, ou quelqu’un à distance, ou les deux, les petits changements font aussi autre chose : ils raccourcissent la boucle de retour sur la direction prise. Si l’approche est mauvaise, vous le découvrez au bout d’une demi-journée plutôt qu’après une semaine de travail à jeter, avec la bonne volonté de son auteur.
La consigne pratique est de convenir d’un plafond et de considérer tout dépassement comme devant être motivé. Le code généré, les renommages mécaniques et les montées de version de dépendances sont les exceptions évidentes et devraient de toute façon faire l’objet de changements séparés, précisément pour ne pas dissimuler une vraie modification.
Sur quoi commenter, et ce qu’il faut laisser tranquille
Le schéma de revue le plus dommageable avec un nouveau contributeur externe est celui où tous les commentaires ont le même poids. Vingt remarques arrivent, trois sont des problèmes de justesse et dix-sept des préférences, et l’auteur ne peut pas distinguer les unes des autres. Il corrige les vingt, n’apprend rien de vos priorités, et ralentit.
Marquez explicitement la différence. Un commentaire bloquant dit ce qui ne va pas et pourquoi cela compte. Une préférence dit qu’elle est une préférence et peut être ignorée. Les équipes qui adoptent cette convention voient leurs échanges de revue raccourcir en quinze jours.
- Bloquant : c’est incorrect, c’est dangereux, cela casse une interface dont quelqu’un dépend, ou cela contrevient à la définition du « terminé ».
- À discuter : l’approche fonctionne mais il y a une raison d’en préférer une autre, et cette raison est expliquée plutôt qu’assénée.
- Préférence : nommage, ordre, structure qui vous plaît. Dites-le, et laissez l’auteur décliner.
- Pas de revue du tout : tout ce qu’un formateur de code ou un linter peut trancher. Si cela figure dans un commentaire de revue, c’est votre outillage qui manque.
Une revue dans les deux sens
Un dispositif où les ingénieurs du client relisent le travail de l’équipe externalisée sans jamais l’inverse crée une hiérarchie que personne n’a acceptée. Il gaspille aussi le regard le plus utile dont vous disposiez : celui de quelqu’un qui a vu d’autres systèmes et n’a pas encore appris à accepter le vôtre.
Faites aussi relire les changements internes par les contributeurs externes, au moins dans les domaines où ils travaillent. Cela fait remonter les hypothèses que votre équipe ne remarque plus, cela rend le standard réciproque plutôt qu’imposé, et c’est le moyen le plus rapide de savoir à quel point quelqu’un comprend réellement le système, un signal bien meilleur que n’importe quel entretien.
Automatisez tout ce qui n’est pas du jugement
Mise en forme, ordre des imports, règles de lint, vérification de types, exécution des tests, seuils de couverture si vous en utilisez : tout cela doit échouer dans la CI, pas dans un commentaire écrit par un humain à onze heures du soir. Chacun de ces points soulevé par un humain est une petite taxe sur la relation, et c’est une taxe payée de façon disproportionnée par le dernier arrivé.
Le gain n’est pas seulement la rapidité. C’est qu’une fois les objections mécaniques évacuées, les commentaires restants portent tous sur le fond, et une revue pleine de fond se lit comme de l’implication plutôt que comme un contrôle tatillon.
Quand la revue devient un goulet d’étranglement que vous avez créé
Deux symptômes à surveiller. Le premier est le relecteur unique par lequel tout passe, généralement la personne qui connaît le mieux le système et dispose du moins de temps libre. Ce dispositif paraît sûr et constitue un point de défaillance unique qui empire à mesure que la mission grandit.
Le deuxième est l’approbation silencieuse. Des revues qui arrivent en quelques minutes sans le moindre commentaire, systématiquement, ne sont pas le signe d’un excellent code. C’est le signe que quelqu’un a cessé de lire, généralement parce que la file est devenue assez longue pour que la vider devienne l’objectif. C’est le moment où la revue a cessé d’être du management pour devenir de la paperasse, et où les défauts qu’elle attrapait arrivent désormais en production.
Les deux se corrigent de la même façon : plus d’une personne capable de relire chaque domaine, et une file d’attente assez courte pour qu’une lecture sérieuse soit possible. Si vous ne parvenez pas au second point, vous avez pris en charge plus de livraison que vous n’avez la capacité d’en piloter, ce qui est un problème d’échelle et non de revue.