Vous êtes développeur ou CTO et travaillez sur une application legacy, souffrant de nombreux défauts et bugs ? Retrouvez le chemin vers l’efficacité en mettant en place quelques bonnes pratiques, comme la revue de code.

Revue de code

Nous avons déjà vu lors d’un précédent article que la mise en place d’une plateforme d’intégration continue permettait d’améliorer la qualité de l’application.
Cette fois, nous allons voir comment les développeurs peuvent, avec un peu de rigueur et un minimum de temps à investir, améliorer la qualité à court et à long terme.

J’ai eu l’occasion, à travers mes différentes missions, de mettre en place ou d’affiner le procédé de revue de code, quelque soit la taille et la qualité de l’application à mon arrivée.

Mais… Qu’est ce qu’une revue de code ?

La revue de code est un processus outillé qui doit se faire juste avant l’intégration du développement à la branche principale. Cette revue de code fait généralement partie de la Definition of Done.
De nombreux outils facilitent l’opération de revue de code.

Comment mettre en place un système de revue de code ?

Afin de pouvoir effectuer la revue de code de façon efficace et utile, je recommande de :

  • partager un code style au sein de toute l’équipe ou des équipes qui interviennent sur l’application👉 Partager un code style permet de minimiser le nombre de lignes modifiées inutilement et automatiquement par le formateur. Ainsi, seules les lignes véritablement modifiées lors des développeurs seront mises en évidence, laissant moins de chances à une coquille de passer à travers le filet 😉
  • laisser n’importe quel développeur de l’équipe de faire la revue, peu importe sa séniorité ou son ancienneté sur le projet. Attention toutefois au cas où un junior relit le code d’un autre junior car les gains ne sont pas au rendez-vous et cela peut-même être contre-productif. Dans le cas où un junior relit le code, il peut être nécessaire qu’un développeur plus expérimenté l’assiste, ou fasse une dernière validation après lui, afin de valider la pertinence des remarques et la qualité du code👉 Même en tant que développeur senior, votre code a tout intérêt à être revu par un autre développeur. Cela encourage la collaboration, le mentoring et le partage de la connaissance
  • mettre en place un environnement de review

La gestion des branches, un pré-requis pour réussir

Pour commencer, il faut choisir un gestionnaire de sources facilitant cette pratique. À ces fins, je ne peux que recommander un outil tel que Git qui allège la gestion d’une multitude de branches.

Le procédé de gestion GitLab Flow, basé pour cette partie sur celui de GitHub, utilise des branches de fonctionnalités.

GitLab Flow

Ce sont ces branches qui doivent être revues avant d’être intégrées à la branche master.

Workflow

Avec le fonctionnement en feature branches et merge request (ou pull request sur GitHub et d’autres), la revue du code se fait plus facilement car toutes les remontées, échanges et questions sont localisées au même endroit.
Il est également possible d’inclure les remontées automatiques d’outils de la plateforme d’intégration continue.

Lors de la création de la merge request, il est important que l’on retrouve le n° de la fiche d’évolution, correctif, etc. dans le nom de la branche. Le titre ou la description de la merge request doit être assez explicite pour que le relecteur puisse se placer dans le contexte.

Une checklist peut dans un premier temps permettre de ne rien oublier. Cette checklist, constituée par l’équipe, doit être vivante et évoluer avec le temps :

  • si elle n’est pas utilisée, débarrassez-vous en
  • si des items ne sont plus d’actualité, retirez-les
  • essayez de garder la liste courte et priorisée

💡 Quand c’est possible, il peut être intéressant de transposer certaines règles sur SonarQube ou tout autre outil d’analyse du code et par conséquent retirer la règle de la checklist.

Attention ⚠

Il est important que la phase de revue ne soit pas un goulot d’étranglement : lorsqu’un développement est soumis à revue, un autre développeur doit effectuer la revue au plus tôt. Il ne s’arrête pas dans son propre développement pour ne pas le perturber, mais n’en reprend pas d’autre tant qu’il y a un développement à revoir.
On évite ainsi que de trop nombreux développements soient en attente, en bloquent d’autres, et amènent à résoudre trop de conflits.

Si cette dernière recommandation n’est pas suivie, une situation désagréable se produit souvent en fin de sprint : des fonctionnalités ne sont pas livrées car elles ont été bloquées trop longtemps.

Privilégiez la livraison de fonctionnalités pour avoir un retour plus rapide.

Le retour sur investissement est considérable

Certes, effectuer une revue de code peut s’avérer coûteuse en temps, mais c’est rentable :

À long terme, le temps passé est rapidement amorti car revenir sur du code sera plus facile.
À court terme, cela permet de corriger efficacement les bugs, identifier et anticiper des failles, etc. mais aussi être force de proposition pour proposer de nouveaux développements.

L’ensemble de l’équipe s’approprie l’application.

Comment effectuer une revue de code ?

Dans un premier temps, je conseille d’effectuer la revue de code en lisant la fiche à l’origine du besoin pour connaître la raison du développement. Il est très intéressant d’imaginer comment vous, vous auriez effectué ce développement, notamment pour s’améliorer, ou proposer votre idée du développement. Il est plus facile de voir des failles, des oublis ou même de vous faire penser à de nouvelles choses en procédant ainsi.

Dans un second temps, je conseille de lire les changements et de comprendre les raisons qui ont poussé à opter pour telle ou telle stratégie, sans aide ou informations supplémentaires de la part du développeur. Si vous ne comprenez pas le code, c’est qu’il n’est pas assez clair ou logique.

Il peut être intéressant d’échanger avec le développeur directement pour lui faire des retours mais, pour ma part, je préfère effectuer la revue de code principalement sur la merge request pour plusieurs raisons :

  • laisser une trace, pour que ce ne soit pas oublié lors de la correction (GitLab permet de marquer un retour comme “fait”)
  • être vu par d’autres membres de l’équipe qui pourraient continuer la revue de code, et éviter ainsi de les priver de discussions importantes
  • ouvrir un fil d’échanges

Si une ligne vous semble étrange ou que vous ne la comprenez-pas, n’hésitez pas à questionner l’auteur. La communication est la clé du succès d’une équipe.

Environnement de revue

Lors de mes derniers projets, j’ai eu l’occasion de mettre en place un environnement de revue, sur lequel sont déployées les différentes branches fonctionnelles. L’application ainsi déployée correspond à la nouvelle fonctionnalité développée et/ou au bug corrigé, facilitant son test.
Cet environnement peut par conséquent être accessible par un point d’entrée différent pour chaque branche fonctionnelle.
Exemple : la branche “user-management” est déployée sur https://user-management.review.myapp.com et GitLab en fait mention sur la merge request

Cet environnement de revue est largement bénéfique à l’équipe : il permet de gagner un temps considérable. Le relecteur ne perd pas son temps à changer son espace de travail, à compiler, déployer, etc. L’environnement est systématiquement créé de la même façon.

💡 Lors de la création de l’environnement, il est agréable et utile d’y avoir des données pré-initialisées. Avec Liquibase, il est possible de définir un contexte “review” qui permet de jouer des scripts pour ces environnements spécifiquement.

Je recommande l’utilisation de Docker, avec éventuellement Kubernetes, idéal pour automatiser le déploiement d’un environnement rapidement et de façon identique.

Et vous, avez-vous mis en place un système de revue de code sur votre projet ? Avez-vous constaté une amélioration flagrante de la qualité de l’application ?

Quelques liens

Auto DevOps
Livrer de la qualité tout en restant productif

Testé et approuvé TalanLabs