Métier, qualité et équipes · Débutant

Revue de code qui améliore plutôt que retarde

En une ligne : Une bonne revue est petite, rapide et centrée sur la correction et la maintenabilité — pas sur les préférences de style qu'un outil automatique devrait appliquer.

Taille

Une demande de fusion de deux cents lignes reçoit de vrais commentaires ; une de deux mille reçoit « ça semble bien ». Divisez. Si vous ne pouvez pas diviser, écrivez dans la description un chemin de lecture recommandé.

Sur quoi commenter

Correction, cas limites, sécurité, performances aux endroits sensibles et clarté pour celui qui le lira dans un an. Style, espaces et ordre des imports — pour un outil automatique, pas une personne.

Formulez les commentaires comme une question ou une suggestion, et marquez ce qui bloque et ce qui n'est qu'une opinion. « Bloquant : cela permet l'accès à la ressource d'un autre utilisateur » est plus clair qu'un indice poli.

Délai de réponse

Une revue qui attend deux jours arrête les gens et produit de longues branches. Fixez une norme — par exemple, répondre dans la demi-journée — et traitez-la comme tout engagement d'équipe.

Pour aller plus loin

Ajoutez à la liste de vérification de la revue des éléments difficiles à appliquer automatiquement : un test a-t-il été ajouté, le changement est-il compatible ascendant, la documentation a-t-elle été mise à jour, et que se passe-t-il en cas d'échec. Ces quatre questions capturent la plupart de ce qui est oublié.