Introduction
Lors de la révision de nombreuses demandes d'extractions (pull requests), j'ai adopté une approche simple : si mes commentaires sont des détails, des suggestions, des questions ou des problèmes non bloquants, je les laisse et approuve la demande en même temps.
Contexte Technique
Pour comprendre pourquoi je laisse des commentaires même si j'approuve, il est important de noter que les commentaires montrent que quelqu'un a réfléchi au problème et à la solution, et se soucie de ce qui arrive au code. Ils offrent parfois l'occasion d'apprendre ou de mettre en surface des malentendus, des hypothèses ou des risques cachés.
Je fais confiance à mon équipe pour considérer et mettre en œuvre mes commentaires si nécessaire. Notre équipe est suffisamment agile pour apporter les changements rapidement, et nos tests d'intégration continue (CI) valident les modifications en un temps raisonnable.
Analyse et Implications
Cette approche suppose que l'on fait confiance à son équipe et que les commentaires sont une forme de signalisation utile. Cependant, certaines configurations de référentiel peuvent rendre cette approche moins efficace, comme le réinitialisation des approbations lorsqu'un nouveau commit est poussé vers la branche de la demande.
Il est également important de noter que cette approche fonctionne mieux avec des outils de faible configuration qui éliminent de nombreux commentaires triviaux, comme les linteurs, les formateurs automatiques, les vérificateurs de types et les analyseurs de sécurité.
Perspective
Pour les commentaires bloquants, je décide au cas par cas, en fonction du type de problème, du projet et de la personne dont je révise le code. L'objectif est d'arriver à un point où la plupart des commentaires sont non bloquants, car l'équipe est fortement alignée.
Enfin, je recommande d'essayer cette approche avec un membre de l'équipe avec qui vous avez un bon rapport, en laissant un commentaire sur la demande qui indique que vous approuvez mais suggérez également des améliorations.
