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.
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.
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.
Afin de pouvoir effectuer la revue de code de façon efficace et utile, je recommande de :
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.
Ce sont ces branches qui doivent être revues avant d’être intégrées à la branche master.
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 :
💡 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.
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.
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.
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 :
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.
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 ?
Auto DevOps Livrer de la qualité tout en restant productif
