Avec les agents de code, on produit plus vite qu'on ne relit. Le goulot, c'est maintenant la relecture.
Sur quinze mois, j'ai relu à peu près deux fois plus de pull requests que je n'en ai écrites, sur huit dépôts et trois stacks. Je le vois comme du temps donné à l'équipe : une pull request qui n'est pas relue, c'est du code que personne n'a lu qui part en production.
Trois habitudes qui rendent la relecture possible.
Livrer petit. Mes pull requests font deux à cinq fichiers en médiane. Une PR qui touche trois sujets ne se relit pas, elle s'approuve par fatigue. J'en ouvre trois.
Découper un gros chantier en étapes lisibles. Le helper, puis l'interface, puis le branchement aux données, puis les tests.
Écrire le pourquoi, pas le quoi. La description dit ce que ça change et pourquoi. Le diff montre déjà le reste. S'il y a une décision discutable, je l'écris dans la PR plutôt que d'attendre qu'on la trouve.
Ce que j'attends d'une revue : qu'on discute les décisions, pas la syntaxe. Le formatage est un travail d'outil, pas de relecteur.
Relire demande de comprendre le code de l'autre, pas seulement de vérifier qu'il compile. C'est aussi un bon moyen d'apprendre une base de code qu'on ne connaît pas encore.
Amine Affif, développeur full-stack à Paris. amineaffif.com
