ProgrammationJ'ai traduit un excellent article de Alberto Gutierrez sur son blog : "5 tips to make good code reviews"

Les revues de code sont l'une des plus importantes pratiques d'ingénierie.

Les revues de code améliore la qualité du code grâce aux suggestions faites par le réviseur du code.
Les revues de code sont un excellent outil pour enseigner indirectement à d'autres développeurs les parties du système qu'ils auront à maintenir plus tard.
Les revues de code encouragent les gens à apprendre les bonnes pratiques avec d'autres développeurs.
Les revues de code peuvent être utilisées comme une validation de la clarté et la simplicité du système.

Vous avez peut-être remarqué que je n'ai pas mentionné dans cette liste que les revues de code pouvaient aider à trouver des bugs et veiller à faire respecter les normes de codage ; c'est parce que :

1. Les revues de code NE DOIVENT PAS être effectuées pour trouver des erreurs dans le code.
2. Les revues de code NE DOIVENT PAS être effectuées pour faire respecter les normes de codage.

Il y a 10 ans, ces deux derniers points auraient effectivement eu un sens dans vos revues de code, mais plus maintenant. Aujourd'hui, cela doit normalement être couvert par vos tests automatisés et par certains outils d'audit de code qui devraient pouvoir vous encourager à respecter vos normes de codage. Cela dit, cela ne signifie pas qu'il est mauvais de détecter un bug ou un problème de respect des normes de codage, cela signifie que les trouver ne constitue pas un objectif de la revue de code.

A partir de là, suivent mes cinq conseils pour faire de bonnes revues de code.

1. Faites fréquemment des revues de code

Moi-même, j'ai déploré que des revues de code soient menées tardivement, j'ai l'habitude de travailler dans une société où une énorme revue de code de l'application était censée être la dernière étape du développement, et c'était tout simplement inutilisable, avoir des revues de code tardives présentent les inconvénients suivants :

- Plus il y a de code à examiner, plus grande est la probabilité que le développeur n'accepte pas une suggestion de refactorer son code.
- Plus le code est ancien, plus grande est la probabilité que le développeur soit personnellement attaché à son code. Je voudrais rappeler ici l'un des plus grands problèmes des développeurs logiciels, leur ego, si un développeur conçoit quelque chose, le fait fonctionner, peu importe que ce soit infect, il y a beaucoup de chances que son ego interfère avec toute suggestion d'améliorer la conception.
- Plus la date de livraison est proche, moins on accorde d'importance aux améliorations du code.

Mon approche personnelle est de faire des revues de code à chaque fois que je viens de terminer de coder quelque chose de non trivial, et cela veut donc dire généralement plusieurs fois par jour.

2. Faites des revues de code informelles et courtes

Oubliez la check-list, tournez lui autour et demandez 5 minutes d'attention à votre collègue à côté de vous, si vous avez une check-list, l'une des 2 choses vont arriver :

1° Les revues de code seront uniquement limitées à ce qui est dans la check-list.
2° Les revues de code deviendront des formalités, les gens s'assiéront ensemble le moins longtemps possible et prétendront qu'ils se soucient du code.

Mener des revues de code courtes et informelles vous aidera à engager des conversations ouvertes dans lesquelles la personne ne se sent pas "auditée", mais plutôt conseillée.

3. Réalisez vos revues de code avec différents réviseurs

C'est une bonne idée, si possible, de ne pas toujours passer par la même réviseur de code, il y a trois raisons principales pour rechercher différents réviseurs chaque fois que vous voulez mener une revue de code :

1° C'est bien de disposer de différents points de vue.
2° Plusieurs personnes seront capables de maintenir votre code dans l'avenir.
3° C'est une équipe qui mène cette activité.

4. Conservez une attitude positive

Encore une fois, rappelez-vous l'un des pires problèmes des développeurs, leur ego, avoir une attitude positive contribuera à rendre la revue de code beaucoup plus agréable, et tous les participants seront plus enclins à accepter vos suggestions, et n'oubliez pas : vous n'êtes pas le code !

5. Apprenez à apprécier les revues de code

C'est le plus important conseil, si vous êtes dans une équipe où les gens apprécient les revues de code, vous entrerez dans une dynamique où tout le monde sera engagé à fournir un code de qualité qui ne semble pas bon uniquement pour eux-mêmes, mais à toute l'équipe.