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 !
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 :
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 :
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 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.
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.
Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition.
Crafted from Bordeaux, France.
©2023 Promyze – Legal notice
NEW: Introducing AI for generating coding practices and discussions for your Promyze workshops |
Social media