A la découverte de la revue de code

Vous avez certainement déjà entendu parler de revue de code. Vous souhaitez mieux comprendre les principes de la revue de code, les avantages qu’elle apporte et que les points importants à surveiller pour qu’elle se déroule dans de bonnes conditions ? C’est tout l’intérêt de cet article !

La revue de code, c’est quoi ?

Le principe de la revue de code est de faire relire par une ou plusieurs personnes des parties du code source écrites par une autre personne. Cette démarche s’inscrit dans un processus d’amélioration continue du code et de sa qualité. Plusieurs objectifs sont visés lorsque l’on met en place une revue de code :

1. Identifier des bugs ou des problèmes au plus tôt. Il faut toujours garder en tête que plus un bug est trouvé tardivement, plus il coûte cher à résoudre. La revue de code ayant généralement lieu quelques jours après l’écriture du code, le coût de résolution sera maîtrisé. 

2. Produire un code propre et maintenable. Un code de qualité est avant tout un code compréhensible par n’importe quelle personne autre que son auteur. Un code est d’ailleurs plus souvent lu qu’écrit. La revue permet de s’assurer que d’autres personnes comprennent ce code et pourront le retravailler plus tard. 

3. Augmenter la connaissance du code dans l’équipe. Relire du code sur lequel on intervient pas directement permet aussi de s’approprier d’autres parties du code. Une étude de 2016 menée chez Google mettait justement cela en lumière, puisqu’au bout d’un an, les développeurs avaient en moyenne relu 2 fois plus de fichiers que le nombre de fichiers dans lesquels ils avaient modifiés du code. 

4. S’assurer que les normes, standards et bonnes pratiques définies dans l’équipe sont suivies. C’est surtout un bon moyen de ré-expliquer certains concepts, surtout si l’on relit le code d’une personne qui vient de rejoindre l’équipe. 

En 1976, Michael Fagan a théorisé et étudié les bénéfices des processus de revue de code, mettant en avant des gains en productivité et sur la détection de bugs. En effet, les bonnes pratiques étant mieux comprises et les problèmes identifiés plus tôt, on imagine facilement moins de temps consacré à la correction de bugs a posteriori.

Comme toute pratique, la revue de code peut s’avérer contre-productive si elle est mal exécutée ou mal comprise par l’équipe. Chez certaines personnes, le terme “revue” peut laisser penser à un mode opératoire de contrôle ou de surveillance visant à formuler des critiques négatives sur le code produit des développeurs. Il est donc très important de bien clarifier et partager les objectifs auprès de toute l’équipe, et de mettre en avant la démarche d’amélioration continue. 

L’état d’esprit et la culture d’équipe vont fortement impacter la manière dont les revues de code vont se dérouler. 

Les pré-requis qui nous paraissent indispensables sont ceux définis par les 10 commandements de la programmation sans ego (Egoless Programming), issus de l’ouvrage “The Psychology of Computer Programming” de Jerry Weinberg (1971). Si leur présentation fera l’objet d’un autre article, il faut retenir que ces commandements visent à améliorer la collaboration entre développeurs, en détachant son “ego” du code produit. 

Le code est une propriété collective et chaque développeur doit faire preuve d’ouverture d’esprit, d’humilité, de prise de recul sur son code, d’empathie envers les autres, et savoir accepter si d’autres personnes proposent des meilleures décisions que les siennes. Cela paraît être du bon sens, mais leur application est loin d’être systématique !

Chaque équipe va adapter la fréquence des revues de code en fonction de ses besoins et de son contexte. Chez certaines, elles auront lieu systématiquement à chaque fusion de branche de développement(Pull/Merge-Request). Chez d’autres, elles se feront plus ponctuellement (1 fois par semaine) sur des parties plus centrales du code. Dans tous les cas, il y a certaines bonnes pratiques à suivre, à la fois pour le submitter et le reviewer : 

• Limiter la taille de la revue à 400-500 lignes Max. C’est déjà largement suffisant comme quantité de code à relire, et l’objectif étant de ne pas rester superficiel mais de rentrer en profondeur dans le code, il vaut mieux ne pas soumettre trop de code. Au-delà, le relecteur commencera à fatiguer et perdra naturellement en vigilance. 

• Pour l’auteur qui soumet une revue, une checklist de points à vérifier doit avoir été validée : le code compile, les tests unitaires sont OK, l’intégration continue est au vert, les bonnes pratiques et conventions ont étés relues… On fait ici preuve d’attention pour la personne qui relit le code !

• Pour le relecteur, une checklist de point à vérifier (lisibilité du code, architecture, respect des conventions, …) doit avoir été établie en amont et partagée au sein de l’équipe. Cela permet de bien définir la portée de la revue, et d’éviter des discussions qui pourraient trop déborder. A l’inverse, on évitera aussi d’abuser du “pinaillage” dans les commentaires, qui peuvent générer de la frustration les auteurs.

• Les commentaires du relecteur doivent être constructifs et suggestifs. Relire du code fait appel au savoir-être de chacun, et la façon de formuler des commentaires est très important : savoir complimenter le travail bien fait, proposer des suggestions et non pas imposer des corrections, pointer du doigt le code et non la personne, faire preuve d’empathie…  On évite de dire haut et fort dans l’open space “Qui m’a écrit code immonde ?”

Si le schéma qu’on retrouve souvent dans une équipe est que le profil “TechLead” soit la seule personne à relire le code, il est également pertinent d’inviter chaque personne à participer en tant que relecteur. Après tout, tout le monde peut apporter sa vision des choses et de nouvelles idées, que l’on soit junior ou senior. Et même en étant senior, on doit toujours chercher à s’améliorer et personne n’est infaillible !

Un exercice de communication pour une équipe performante

Un des objectifs connexes de la revue est de renforcer la communication au sein d’une équipe, et de faciliter la montée en compétences des développeurs. C’est un très bon exercice de dialogue et de partage qui renforce la cohésion et le bien-être au sein de l’équipe. Les revues sont d’ailleurs très révélatrices des “soft skills” de chaque personne. La réussite d’un projet passe principalement par des échanges sains et productifs entre chaque partie prenante. 

Une étude menée chez Google en 2015  a mis en lumière les facteurs-clés de performance d’une équipe. Au delà de critères telles que l’expérience et les diplômes, le facteur principal qui ressort est celui de la sécurité psychologique. Elle reflète le confort et l’aisance des développeurs à parler ouvertement de problèmes en présence des autres personnes dans l’équipe, ainsi qu’à prendre des risques et des initiatives. Si la confiance règne dans une équipe, chaque personne se sent plus libre d’agir sans craindre de la réaction des autres, et surtout sans la crainte d’échouer. Pratiquer la revue de code, c’est aussi instaurer cette sécurité psychologique qui présente tant d’avantages pour une équipe !

Enfin, nous avons mentionné plus haut que la revue de code augmente la connaissance du code dans l’équipe. Avez-vous entendu parler du Bus Factor ? C’est le nombre de personnes au-delà duquel votre projet ne peut se poursuivre de manière viable si elles sont heurtées par un bus. C’est une façon de d’illustrer la concentration d’expertise au sein d’une équipe. En invitant chaque personne à relire du code qu’elle n’a pas écrit, et donc à s’approprier d’autres parties du code, cette connaissance est mieux répartie dans une équipe. 

Alors, envie de tenter l’expérience ?

Encore des doutes sur les gains de la revue de code ? Si elle est bien appliquée, cette pratique apporte des gains évidents à toute l’équipe. Notre plateforme Promyze, dédiée à la définition et la diffusion des bonnes pratiques, s’appuie sur les Ateliers Craft, formats de revues collectives ayant pour objectif de se concentrer sur la définition des bonnes pratiques. Reposant sur les discussions et les prises de décision en équipe, Promyze exploite les mécanismes de la revue de code pour aider l’équipe à construire sa base de bonnes pratiques.