Dans un projet informatique on est amené à produire beaucoup de lignes de code. Lorsque l’on écrit un programme on veut s’assurer que le code livré soit de :

  •  Qualité,
  •  Maintenable,
  •  Sur,
  •  Réponde aux besoins métiers
  •  Etc…

Pour cela, on a plusieurs outils/stratégies que l’on peut mettre en place :

  • Outils de formatage de code,
  • Métrique de qualité de code,
  • Tests unitaires
  • Tests d’intégrations,
  • Revue de code.

 La plupart des points évoqués ci-dessus sont des outils à mettre en place qui vont s’exécuter de manière mécanique en produisant un résultat binaire -> OK – KO.

On va s’attarder sur la revue de code. Contrairement aux autres outils/stratégies, la review est une tâche, finalement, assez compliquée.
Basiquement la PR review peut être perçue comme un simple relecture du code d’un collègue. Mais en réalité, cette étape présente des enjeux beaucoup plus importants.
Je vous propose de faire un tour d’horizon des implications que peut présenter une revue de code dans un projet.

Faire une PR

Avant de parler de la revue de code, parlons rapidement de ce que peut représenter le fait de faire une PR. Lorsque l’on créé une PR, cela veut dire que l’on va partager le résultat de son travail. L’objectif de ce partage est d’obtenir une validation de la part d’un tiers.

Pour que la PR puisse être relue dans de bonnes conditions, il est nécessaire de donner un maximum de contexte à celui qui va relire votre code. En effet, sur un projet tout le monde n’a pas une connaissance détaillée de l’activité de chacun. Aussi, pour simplifier et optimiser le travail du relecteur, il est intéressant d’ajouter en en-tête de la PR, une explication donnant du contexte ainsi que le scénario métier permettant de valider la PR. De cette manière, lorsque le relecteur commencera sa PR, il pourra prendre connaissance rapidement du contexte sans devoir aller poser des questions, aussi, cela permet de rester aligner sur les objectifs de la PR d’un point de livrable. Il aura en main le scénario permettant de valider d’un point de vue métier la PR ; par conséquent, il pourra arriver plus rapidement à se concentrer sur la revue de code.

Cette validation va passer par des commentaires, des remarques et même des critiques. D’un point de vue humain ce n’est pas évident de se trouver dans cette situation de ‘jugement’.

Face à cela, nous ne sommes pas tous égaux. Certains garderont de la distance, d’autres prendront les choses très à cœur. Au-delà des aspects techniques que peuvent représenter une PR, derrière on trouve une problématique purement humaine mettant en cause la sérénité au sein d’une équipe.

Faire des revues de code est une étape essentielle dans le processus de développement. Elles permettent de partager les évolutions de la base de code, d’apporter un regard tiers sur des solutions techniques, d’identifier des points améliorables, un moment de partage, etc. C’est un cercle vertueux, si l’on s’astreint à respecter quelques règles

Alors comment faire pour que cela se passe bien ?

Les règles

La première étape est de définir de manière collégiale la manière de faire une review au sein du projet.

  • Lecture statique du code,
  • Exécution des tests unitaires,
  • Déroulement d’un scénario permettant de valider au runtime le code
  • Périmètre de la revue de code,
  • Se concentrer uniquement sur le code modifié
  • Etc.

(liste non exhaustive)

En définissant ces règles, on s’assurera d’avoir une vision commune sur la manière de mener une revue de code et d’avoir un langage commun pour se comprendre.

La communication

D’une manière générale, la communication est un élément central dans les échanges humains. Une fois n’est pas coutume, dans le cadre des PR review, la manière de s’exprimer est capital pour les échanges restent constructifs et profitable au projet.
Faire un commentaire sur une PR n’est pas quelque chose de si évident que ça. Il faut adopter un état d’esprit et faire preuve d’empathie.

Par exemple, lorsque l’on tombe sur un bout de code qui ne semble pas correct ; plutôt que d’imposer un point de vue de manière unilatérale, il est préférable de suggérer une modification en formulant sa remarque sous la forme d’une question.

Aussi, ne pas écrire sa remarque de façon lapidaire. Prendre le temps de détailler son point. En abordant les choses de cette manière, cela positionne les deux protagonistes au même niveau et surtout pour celui qui expose son code cela vient comme une proposition et donne lieu à un échange.

Qui est tu ? Qui suis-je ?

Lors de la revue de code, il y a 2 parties, celui qui expose son code et celui relis le code. Un élément face auquel il faut être vigilant c’est d’aplanir le rôle et/ou la compétence/séniorité de son interlocuteur. 

Par exemple, en tant que junior est-on légitimé à faire une review d’un développeur plus senior ? 

Aussi, je suis développeur et je dois faire la review d’une PR de mon tech lead. Dois-je faire une différence ? Je pense que non, il faut aborder la review en faisant abstraction de ces critères. En effet, chacun a son niveau peut avoir un regard critique (positive). Il faut faire abstraction du profil de la personne afin que celui-ci ne vienne pas biaiser notre revue. 

Si l’on ne s’astreint pas à cette règle, on risque de biaiser la revue de code et du coup, faire une revue de code pas pertinente, voire inutile.

Mais alors pourquoi faire des revues de code ?

Au vu de tous les éléments à prendre en compte pour faire une PR et faire une review, on peut se dire légitiment de l’intérêt de faire tous ces efforts.

Je pense que le ROI derrière la revue de code est très important. Ce processus induit beaucoup de choses qui seront bénéfique pour le projet. Ci-dessous une liste des principaux points :

  • Favorise la communication au sein de l’équipe
  • Donne une visibilité transverse de la base de code à l’ensemble de l’équipe
  • Permet d’éliminer des erreurs à l’aide d’un regard tiers
  • Permet de faire grandir les personnes d’un point de vue technique et humain

Bien évidemment ceci n’est pas exhaustif, mais cela définit déjà pas mal de points de motivation à pratiquer la revue de code.

Conclusion

La revue de code est un élément central dans le monde du développement. Négliger cette tâche sur le projet ou ne pas tenir compte des éléments vus ci-dessus peut nuire à la bonne santé du projet. 

Mauvaise communication => mauvaise relation => mauvaise review => qualité et pérennité du projet engagée == cercle vicieux.

Ce sujet est épineux, n’hésitez pas à partager vos expériences, votre sentiment sur le sujet !