Code review : 4 étapes pour une revue de PR efficace

Étape incontournable dans le développement d’un logiciel ou d’une fonctionnalité, la revue de PR, pour Pull Request (GitLab) ou Merge Request (GitHub et Bitbucket), permet de s’assurer de la qualité du code à intégrer.

Mais pour que ce travail de revue de PR soit efficace, plusieurs étapes sont nécessaires.

1- Créer une branche locale

Lors de la création d’un feature et d’une branche en local, il faut choisir avec soin la branche initiale d’où est tirée cette nouvelle branche.

Il peut s’agir de la branche develop pour une fonctionnalité, mais il est également possible de tirer une branche depuis master pour un hotfix par exemple.

Il faut par contre éviter de tirer des branches depuis des branches qui ne sont pas encore mergées dans la branche principale. Cela risque de créer des difficultés qui seront ingérables avec le temps.

2. Développer la fonctionnalité ou le correctif

Après avoir correctement créé une branche, vous pouvez développer votre code. Pour une meilleure fluidité dans votre travail et dans celui du reviewer, il est important de commiter régulièrement votre code. Cela permet de comparer plus facilement les différentes versions de commits sur les PR, de voir ce qui s’est passé entre deux changements et cela facilite les potentiels revert.

Une fois ces développements terminés, le code peut être rapatrié sur la branche principale. La PR peut être ouverte.

3. Ouvrir la PR

Pour rapatrier le code sur la branche principale, il faut ouvrir la PR :

On push la branche sur le dépôt : Le CLI peut directement afficher un lien d’ouverture (ou de consultation) de la PR associée.

Lors de l’ouverture de la PR sur GitLab, on a le choix de la branche cible (branche sur laquelle on rapatrie la branche sur laquelle on travaille). Il est important de ne pas se tromper et d’ouvrir la PR sur la bonne branche.

Il est possible d’ouvrir une PR même si le développement n’est pas terminé, avec le statut Draft. Il ne faut pas hésiter à utiliser ce statut qui va permettre à tout le monde de voir que le développement est en cours, avec les commits, les pushs, etc. À ce stade, un reviewer peut être affecté pour commencer la revue de PR et faire des retours au fil de l’eau.

Il faut essayer de choisir un nom de PR pertinent et explicite. Le nom par défaut peut ne pas être forcément lisible.

Il ne faut pas hésiter à ajouter des commentaires pour préciser au reviewer les points sur lesquels il y a de potentiels manquements, sur lesquels on a des doutes ou si l’on souhaite lui donner une marche à suivre pour la revue de PR.

Il faut vérifier que notre pipeline est passée, car il y a de fortes probabilités que celle-ci se déclenche au moment où on push notre branche. GitLab va nous permettre de voir si notre pipeline est verte ou rouge.

Il faut également s’assurer qu’il n’y a pas de conflits avec la branche cible, car celle-ci a pu avancer plus vite que nous. Aucune PR ne doit rester avec des conflits, il faut les résoudre en local ou avec GitLab.

Afin de prendre du recul sur son travail, on relit son code et sa PR à tête reposée.

Une fois qu’on est prêt, on peut assigner le reviewer. Le reviewer n’est pas forcément une personne plus compétente techniquement. C’est quelqu’un qui va avoir un regard externe et neutre et qui va pouvoir détecter les erreurs par expérience, lors de la revue de PR.