Code review : présentation des méthodes et outils

La code review fait partie intégrante du développement moderne de logiciels. La révision du code par plusieurs membres d’une même équipe de programmation permet d’en détecter les erreurs et contribue à en améliorer la qualité. Vous pouvez utiliser différentes techniques et méthodes à cet effet ; retrouvez ci-dessous des explications détaillées les concernant.

La code review, ou « revue de code », correspond à une mesure d’assurance qualité dans le domaine du développement de logiciels. Le code source constitue l’élément de base du travail de développement, mais aussi le principal produit de la programmation. Il convient donc de toujours soumettre le code que vous venez de créer ou de modifier à une code review. Cette procédure consiste à laisser un ou plusieurs membres de l’équipe vérifier le travail effectué par un programmeur.

Un projet logiciel comprend une « base de code », c’est-à-dire une collection de fichiers de code qui permettent, une fois rassemblés, de livrer un produit. En plus du code du produit à proprement parler, cette base comprend, entre autres, la configuration, les outils de développement et les tests nécessaires, tous ces éléments étant présentés sous forme de code. L’ensemble de la base de code est géré à l’aide d’un système de contrôle de version, comme Git. Différentes « branches » permettent de gérer plusieurs versions de la base de code parallèlement les unes aux autres. Il est donc possible de développer de nouvelles fonctionnalités sans pour autant modifier la version de production de la base de code.

Généralement, le travail de développement est donc effectué sur des branches de fonctionnalités, intégrées de manière périodique à la branche principale. La révision du code intervient avant la « fusion », c’est-à-dire avant l’association du code nouvellement créé ou modifié avec la base de code existante. Celle-ci a pour but de repérer et d’éliminer les erreurs assez tôt dans le processus, avant la mise en production du code.

La révision du code ne sert toutefois pas uniquement à résoudre les éventuels bogues. Le bon fonctionnement du code, sans erreur et avec la production du résultat souhaité, ne constitue en effet que l’un des prérequis. Il existe de nombreux autres critères de qualité à respecter pour obtenir un « clean code ». La présence de commentaires, la clarté et la cohérence du code, mais aussi le respect d’un certain guide de style et la capacité d’intégration à des systèmes existants constituent d’ailleurs autant de paramètres essentiels qu’il convient de prendre en compte lors de la code review.

Comme le travail de développement est souvent effectué en groupe, la code review ne se contente pas d’améliorer la qualité du code. La révision du code est en effet assurée par d’autres membres de l’équipe de développement, avec des effets sociaux : les nouveaux membres bénéficient de commentaires sur les conventions et les bonnes pratiques, et les connaissances sont mieux échangées et transmises au sein de l’organisation. La revue de code contribue donc à favoriser une certaine culture de la qualité.

De nos jours, même si la revue de code est assurée par des personnes, les processus de code review s’appuient généralement sur des outils spécifiques. Les outils de code review sont efficaces et soulagent toutes les personnes concernées, qui n’ont plus besoin de gérer la coordination complexe et fastidieuse des processus. Elles peuvent donc se consacrer pleinement à la code review proprement dite.

Sur le plan conceptuel, la code review réalisée par des personnes se situe à mi-chemin entre deux méthodes d’analyse automatisées : l’analyse statique et l’analyse dynamique. Voici ce qui les différencie les unes des autres :

Le concept d’une code review est plutôt simple : un ou plusieurs membres d’une équipe de développement (les « réviseurs ») examinent le code nouvellement créé ou modifié afin de vérifier que celui-ci est correct. Les réviseurs lisent le code et identifient toute erreur potentielle, ainsi que toute divergence par rapport aux conventions en place au sein de l’équipe. Les réviseurs peuvent directement apporter des améliorations au code ou transmettre leurs conclusions aux auteurs d’origine, qui s’occupent alors d’intégrer les modifications.

L’idée peut paraitre simple, mais en pratique, le travail lié aux processus de code review peut rapidement prendre de l’ampleur. En effet, le diable est dans les détails : quelles modifications vont de pair et comment celles-ci sont-elles communiquées aux réviseurs ? Comment signaler les erreurs détectées et laisser des commentaires aux emplacements correspondants dans le code et mettre ces derniers à disposition des personnes chargées de l’amélioration du code ? De telles actions ne peuvent être coordonnées que si votre équipe est très petite ou si vous disposez d’outils de code review.

Dans les équipes de programmation distribuées et agiles, la code review fait le plus souvent du processus de développement. Dans le cadre de l’intégration continue (IC), le code est écrit, testé et intégré à la base de code existante de façon continue. La code review assurée par une personne fait alors partie du « pipeline » automatisé de l’IC emprunté par toutes les unités de code. Si le code réussit tous les tests, il est finalement intégré aux systèmes de production et diffusé par l’intermédiaire de ces derniers.

Découvrez avec nous les différentes sections du pipeline d’IC et l’emplacement occupé par la code review dans ce dernier :

1. Écrire du code
   1. Écrire du code sur la branche de fonctionnalité
   2. Tester le code au sein de l’environnement local
       
2. Intégrer le code à la base de code
   1. Analyser et formater le code de façon automatisée sur la branche de fonctionnalité
   2. Effectuer une code review et implémenter les améliorations nécessaires
   3. Fusionner le code avec celui de la branche principale
   4. Déployer et tester la branche principale sur un site de staging
       
3. Produire le code
   1. Fusionner le code avec celui de la branche de publication
   2. Déployer la branche de publication sur le site actif

La code review constitue une étape indispensable du contrôle de la qualité dans le domaine du développement de logiciels. La revue de code sert en effet à vérifier que le code nouvellement créé est aussi irréprochable que possible et qu’il répond bien aux normes de qualité en vigueur dans l’organisation. Il permet, à long terme, de réduire la dette technique et, à plus court terme, d’éviter l’exécution d’un code erroné sur les systèmes de production.

Le code est un outil puissant ; une fois écrit, un même code peut en effet s’exécuter de façon répétée ou simultanée en tant qu’instances multiples. Toute erreur entraîne donc des répercussions, et une petite faute commise à un emplacement central peut donc avoir d’importantes conséquences pour l’ensemble du système. C’est la raison pour laquelle la correction d’erreurs dans le code déjà en cours d’exécution dans un système de production coûte généralement plus cher qu’une correction en amont.

La code review favorise l’égalisation des différences de qualité entre tous les éléments qui constituent la base de code. En effet, la qualité du code peut fortement varier en fonction des circonstances qui prédominent lors de son écriture. Les paramètres suivants sont tous susceptibles d’amoindrir la qualité du code développé par un programmeur :

• Manque d’expérience en termes de programmation
• Faible maîtrise du système
• Connaissance limitée des conventions appliquées par l’équipe
• Stress ressenti lors du développement
• Développement effectué avec des contraintes de temps
• Épuisement mental

Aujourd’hui, l’utilisation du code ne se limite plus à l’écriture de programmes. Le code est en effet un outil d’expression qui se prête bien à la description précise de toutes sortes de systèmes. Il peut, entre autres, être utilisé pour la rédaction de contrats intelligents basés sur la blockchain ou la définition d’environnements Cloud par IaC (Infrastructure as Code). Pour toutes ces approches, une code review peut également s’avérer utile.

Nous vous présentons ici les bonnes pratiques issues d’une étude empirique menée à grande échelle par une équipe de programmeurs de l’entreprise Cisco, par l’intermédiaire de la société SmartBear. Ces bonnes pratiques tiennent notamment compte des limites des réviseurs humains. Le code est un outil complexe, et sa révision requiert la plus grande attention. Or, les capacités mentales des êtres humains restent limitées et finissent par faiblir lorsqu’elles sont sollicitées de manière continue. En cas d’inattention, des erreurs peuvent facilement passer au travers des mailles du filet, ce qui revient à gaspiller le temps consacré à la code review.

Ces bonnes pratiques visent en outre à garantir l’efficacité des processus de code review. Si des erreurs sont détectées, il convient de les corriger. Pour ce faire, il faut disposer de compétences claires et de la possibilité de contrôler les processus, ainsi que de suivre leur avancée. Nous listons ci-dessous quelques-unes des bonnes pratiques que nous avons identifiées :

• Un maximum de 400 lignes de code par session : plus le volume de code est important et plus les erreurs sont susceptibles de passer inaperçues.
   
• Une révision limitée à 500 lignes de code par heure : au-delà, la capacité des réviseurs à identifier d’éventuelles erreurs s’en trouve amoindrie.
   
• Une code review limitée à 60 minutes : si la code review dure plus longtemps, les réviseurs risquent de perdre en concentration.
   
• La définition d’objectifs et l’enregistrement de certaines mesures : quel est le nombre d’erreurs trouvées par unité de temps ou par ligne de code ?
   
• L’annotation du code source par ses auteurs avant toute révision : ces annotations aident les réviseurs à vérifier et à comprendre les modifications du code.
   
• L’utilisation de listes de contrôle : celles-ci devraient énumérer les points à garder en mémoire lors de chaque révision.
   
• La mise en place d’un processus pour la correction des erreurs identifiées : il ne suffit pas de repérer les erreurs. Pour les corriger, il convient de mettre en place des règles et des structures claires.
   
• La promotion des aspects positifs d’une culture de la code review : une erreur ne doit pas être vue comme une faute personnelle, mais plutôt comme une occasion d’apprentissage.
   
• L’exploitation des implications subconscientes liées à l’examen par les pairs : les programmeurs sont plus susceptibles de faire des efforts s’ils savent que leur code est ensuite soumis à une révision.
   
• La mise en place de processus de code review légers : les outils de code review modernes ont amélioré l’efficacité de la revue de code.

De manière générale, la code review est considérée comme essentielle dans le cadre du développement de logiciels ; les avantages que comporte la revue de code sont d’ailleurs évidents. Son utilisation n’est toutefois pas dénuée d’inconvénients. Découvrez avec nous les avantages et les inconvénients de la revue de code.

Le principal avantage de la revue de code tient au fait qu’elle permet d’identifier et d’éliminer les erreurs en amont, avant que celles-ci n’aient de conséquences négatives. Cette méthode s’avère bien plus efficace que l’identification et la correction d’erreurs à une étape ultérieure dans le cycle de vie du code. Si le code erroné est déjà intégré à un système de production, d’autres éléments de ce dernier peuvent dépendre de ce code, rendant ainsi les améliorations plus difficiles.

Les code reviews régulières ne servent toutefois pas uniquement à rechercher les erreurs isolées. Il convient notamment d’analyser la « vue d’ensemble » : comment le code s’intègre-t-il à la base de code ? Une code review continue peut permettre l’identification de modèles généraux et la définition de certaines normes. Les codes smells sont ainsi identifiés et résolus au même titre que les erreurs fonctionnelles. Le cas échéant, il est possible de recourir au réusinage de code et aux patrons de conception afin d’uniformiser plusieurs composants.

Tous les membres d’une équipe de programmation sont impliqués dans le processus de code review, ce qui les amène à communiquer. Sans surprise, les stratégies de code review bien établies contribuent donc à l’amélioration des compétences de l’équipe concernée en matière de code. Les processus de code review permettent d’intégrer et de diffuser les connaissances au sein d’une équipe, et donc d’améliorer les compétences de chaque membre en matière de code.

Au niveau d’une organisation, les code reviews participent au développement d’une culture axée sur la qualité. Les personnes qui savent que leur travail fait l’objet d’une révision ont tendance à fournir davantage d’efforts. Une code review d’environ un tiers du code produit suffit à obtenir des retombées positives.

Bien entendu, la mise en place d’une code review dans une organisation représente du travail. La revue de code est chronophage et mobilise du personnel ; la gestion des processus concernés nécessite en outre de mobiliser des ressources. Ces coûts permettent toutefois d’améliorer la qualité du code ; en effet, n’oubliez pas qu’un code de mauvaise qualité peut lui aussi engendrer des frais considérables.

Sans outils de code review, la revue de code peut s’avérer particulièrement inefficace. Avant l’avènement de la code review légère, les méthodes traditionnelles ont tout particulièrement posé problème. Quel que soit le cas, il est essentiel d’établir des avec précision les objectifs et les exigences en lien avec les processus de code review ; cela permet de mieux calculer le rapport coûts-avantages et d’éviter toute incertitude.

Pour ce qui est des développeurs, les code reviews ont tout pour leur permettre de renforcer leurs connaissances et améliorer leur cohésion d’équipe. Pour ce faire, il est primordial de créer un environnement de travail constructif et collégial. Dans le cadre d’une code review une attitude hostile ou pleine de reproches peut tout à fait traumatiser les personnes concernées. Les nouveaux membres d’une équipe, les personnes appartenant à une minorité et les programmeurs disposant d’une expérience relativement limitée risquent tout particulièrement d’être touchés par ce phénomène.

L’« inspection Fagan » est considérée comme la première forme de code review. Ce processus coûteux mobilisait quatre personnes et nécessitait de nombreuses réunions, ainsi que l’impression du code à vérifier sur papier. Très efficace en termes de détection des erreurs, l’inspection Fagan est une méthode impossible à intégrer au travail de développement moderne, dans toute son agilité.

Parallèlement aux lourdeurs de l’inspection Fagan, il est aujourd’hui possible de recourir à des approches plus légères en matière de code review. Elles supposent toutes la participation de l’auteur (ou des auteurs) du code, ainsi que d’un ou de plusieurs réviseurs.

La méthode d’analyse par-dessus l’épaule constitue la forme de code review la plus simple. L’auteur présente le code écrit à un autre membre de l’équipe de développement (faisant office de réviseur). Celui-ci recherche toute erreur éventuelle, et cette méthode permet également de discuter de la structure du code ainsi que des autres approches envisageables. Comme l’auteur et le réviseur sont en communication directe, l’échange de commentaires est rapide et les améliorations peuvent faire l’objet d’une intégration immédiate.

La code review par-dessus l’épaule s’effectue in situ, sur l’ordinateur de l’auteur. Le réviseur regarde par-dessus son épaule le code qu’il lui présente. Cette technique permet d’utiliser l’ensemble des ressources et des outils disponibles sur la machine de développement. La code review brille par sa simplicité et peut facilement s’organiser de façon ponctuelle.

Sur le plan conceptuel, la revue de code par pair programming ressemble à la code review par-dessus l’épaule. En effet, cette méthode requiert elle aussi les compétences de deux membres de l’équipe de programmation. Ces deux stratégies diffèrent toutefois en termes de chronologie des processus de création et de révision du code. La code review par-dessus l’épaule intervient après la création du code, alors que dans la programmation en binôme, les étapes de mise au point et de révision ne font qu’une.

Dans le cadre de la programmation en binôme, un « pilote » écrit le code et se charge des détails liés à son implémentation. Le réviseur, quant à lui, supervise l’écriture du code et formule des commentaires. Il garde également à l’esprit la vue d’ensemble ; non seulement le code ne doit pas contenir de fautes et fonctionner de façon autonome, mais il doit aussi respecter les modèles et les règles qui s’appliquent à l’intégralité du projet.

Il est essentiel que le pilote et le réviseur intervertissent les rôles régulièrement. Cela leur permet en effet de changer de perspective, mais aussi d’équilibrer les rapports de force et de se ressourcer mentalement. Les membres les moins expérimentés de l’équipe peuvent aussi en profiter pour découvrir ces deux rôles.

Pour modifier ou ajouter du code dans le cadre de projets d’envergure, il est souvent nécessaire de charger plusieurs personnes de la révision du code. La notification par email pour la code review consiste à envoyer un récapitulatif des modifications à toutes les personnes concernées. Les notifications par email se succèdent ensuite, et les modifications sont intégrées jusqu’à ce que la révision soit terminée et que le code soit finalisé.

Comme vous l’imaginez, ce processus peut rapidement être à l’origine d’une certaine confusion si les participants sont trop nombreux. La notification par email pour la code review est d’ailleurs plus efficace si elle est associée à l’utilisation d’outils de code review appropriés.

Les approches modernes en matière de code review sont basées sur des outils de code review spécifiques. Ils permettent de structurer les processus de révision, garantissent leur efficacité et enregistrent certaines mesures. Grâce à ces outils, le processus de révision peut être planifié, contrôlé et vérifié.

Différents outils de code review sont disponibles. Ceux-ci sont parfois intégrés dans des stratégies existantes en lien avec l’intégration ou la livraison continue (IC/LC). Découvrez avec nous les différents types d’outils disponibles, ainsi que des exemples.

Les outils de code review ont pour base les systèmes de contrôle de version distribués (« Distributed version control systems », ou DVCS), notamment le très populaire logiciel Git. Ceux-ci permettent de suivre les modifications du code et de les afficher sous la forme de « diffs ». Les plateformes basées sur Git comme GitHub et GitLab améliorent la présentation et mettent avant tout en avant le travail d’équipe. Grâce à leurs demandes de fusion, ces plateformes proposent une code review intégrée avant toute acceptation d’un nouveau code.

Ces outils s’appuient sur Git ou d’autres systèmes de contrôle de version distribués (DVCS). À partir de là, ils utilisent généralement une interface utilisateur basée sur le Web afin d’organiser des code reviews en équipe. Plusieurs outils de code review proposent également leur propre interface de ligne de commande (« Command line interface », CLI).

GitHub est considérée comme la plateforme standard pour la gestion des référentiels Git basée sur le Web. Pour la code review, le mécanisme prédominant est celui des « pull requests ». Pour apporter des modifications au code d’un référentiel, il suffit de suivre un schéma simple :

1. Cloner le référentiel en tant que copie locale.
2. Effectuer les modifications dans la branche concernée.
3. Créer une « pull request » : il s’agit de demander au chargé de maintenance du référentiel de vérifier les modifications et, en cas d’évaluation concluante, de fusionner celles-ci avec le référentiel principal.

L’outil de code review Review Board donne la priorité aux demandes de révision. Avec son interface Web moderne et conviviale, il propose une vue d’ensemble de toutes les demandes de révision en cours sur les référentiels et les branches. La commande « rbt » garantit un accès rapide à partir de la ligne de commande. En plus du code, il est possible d’intégrer des graphiques et des documents PDF aux processus de révision.

Installée sur un serveur dédié, Gerrit agit comme une interface entre les modifications apportées au code et la base de code de production. Les modifications sont vérifiées par code review et doivent être acceptées avant de passer en production. Une installation Gerrit est constituée d’un environnement Git autohébergé avec un accès SSH, mais aussi d’une interface Web disponible par HTTPS. En plus de notifications optionnelles par email ; Gerrit propose un système de vote relatif aux modifications du code.

Développé par SmartBear, l’outil de code review Code Collaborator met plutôt l’accent sur les récits utilisateur, c’est-à-dire de spécifications de fonctionnalités centrées sur les utilisateurs, transposées en code puis validées par des tests. En plus de l’équipe de programmation, cet outil étend la participation aux responsables et aux équipes de test et permet de vérifier de façon cohérente les modifications apportées aux récits utilisateur, au code et aux plans de test.

Connus sous le nom de « linters », ces outils servent à analyser et à formater le code de manière automatisée, et donc à le préparer pour une code review. Sur le plan technique, cette analyse reste statique. En effet, si le code est lu, il n’est pas exécuté. Les linters sont utilisés dans le cadre du pipeline d’IC, de manière à uniformiser le formatage du code ou encore à adapter le code par rapport au guide de style.

L’analyse statique renvoie aussi des mesures relatives au code, comme le nombre de lignes de code (« Lines of code » ou LOC) par fichier, par classe ou par fonction. Les linters sont également capables de détecter les erreurs les plus fréquentes avant la révision du code par des êtres humains. Il peut par exemple s’agir d’erreurs de type, d’injections SQL et d’erreurs hors limites.

Sur le plan conceptuel, ces outils relativement récents fonctionnent comme des éditeurs de code basés sur le Web et capables de synchroniser les modifications entre plusieurs utilisateurs. Ils permettent de se livrer à la programmation en binôme dans des environnements partagés et à des code reviews par-dessus l’épaule qui se jouent des frontières géographiques. Ces outils ont énormément gagné en popularité avec la pandémie de coronavirus.

L’environnement Replit basé sur le Web, ainsi que l’outil LiveShare intégré à l’éditeur Visual Studio Code de Microsoft, peuvent être utilisés en tant qu’éditeurs HTML collaboratifs. Ces deux outils connaissent bien évidemment d’autres langages et permettent de travailler en collaboration sur plusieurs fichiers, mais aussi d’exécuter du code.