C’est quoi la revue de code ? À quel niveau s’inscrit-elle ? À quoi sert-elle selon toi ?

Strictement parlant, la revue consiste, pour le développeur, après avoir réalisé une fonctionnalité, à proposer son code en relecture, et à inviter les intervenants à donner leur avis ou à proposer des améliorations, si nécessaire.
C’est l’une des dernières étapes de développement avant la mise en production. C’est surtout l’occasion pour le développeur de montrer son travail à d’autres personnes.
Dans le cadre du pair ou mob programming, la revue n’est pas forcément utile, car tout le travail est réalisé conjointement en amont. Mais dans le cas d’un exercice solitaire, c’est une étape essentielle.
Dans le cadre d’un projet en intégration continue, c’est un jalon indispensable. Son rôle est de concrétiser une fonctionnalité, en assurant l’accord des membres de l’équipe.

Qui participe à la revue de code ?

La plupart du temps la revue se fait entre deux personnes mais ce n’est pas une obligation. Plusieurs participants peuvent intervenir et laisser des commentaires. Il est même parfois possible de commenter les commentaires ! Le relecteur n’est pas infaillible, loin de là. Ainsi, il n’est pas inutile que ses avis soient parfois remis en question.
En général, la revue se fait entre les membres d’une même équipe. Bien qu’il soit plus rare d’effectuer des revues transverses (entre différentes équipes), la pratique est particulièrement intéressante. Elle permet de sortir de son « pré carré » et de recueillir des avis originaux ou atypiques.

Comment la revue de code est-elle mise en place sur ton projet actuel : technique et outils utilisés ?

Suivant la mission ou le type de projet, l’étape de revue est appliquée de manière plus ou moins stricte. Sur l’une de mes missions, elle était optionnelle. Il n’y avait pas de ligne directrice et elle se faisait au bon vouloir de chacun ou suivant les disponibilités du Tech Lead attitré.
Sur notre projet actuel, elle est beaucoup plus encadrée. Après avoir créé sa MR (Merge Request, dans le vocabulaire de Gitlab), le développeur l’assigne à une personne de référence et ajoute si nécessaire un ou plusieurs « reviewers ».

Généralement, la revue se fait en ligne, en utilisant l’interface de Gitlab, qui permet (comme d’autres outils du même type) de se focaliser sur les parties de codes réellement modifiées en les soulignant grâce à des codes de couleur. L’outil WYSIWYG (What You See Is What You Get) permet de mettre en surbrillance les correctifs proposés et de naviguer dans le code sans avoir à se déplacer manuellement de fichier en fichier.
Dans les cas difficiles, il est souvent utile de rapatrier en local la branche concernée. Ainsi, cela permet de tester des solutions alternatives dans son propre éditeur. Il m’arrive souvent, dans le cadre d’une revue, de créer des tests unitaires temporaires pour vérifier tel ou tel point de détail. Il n’est pas inutile non plus de démarrer le projet et de le tester fonctionnellement pour mieux comprendre les points de détail ou les problèmes d’interface utilisateur.

Quels sont les apports et les limites de cette pratique sur ton projet ?

Le temps passé en revue peut parfois poser problème. Les allers-retours imposés par les correctifs et l’approbation des commentaires augmentent significativement la durée de vie d’une US (User Story). Il faut trouver un juste équilibre et savoir quand s’arrêter. Ne pas trop s’attarder sur les points de détail anecdotiques ou peu impactants.
Les problèmes de compréhension peuvent aussi ralentir le projet et nécessitent souvent des échanges en personne pour en venir à bout. Mais c’est aussi un atout car ce sont justement ces échanges qui permettent de souder une équipe et d’avoir un horizon commun en partageant les bonnes pratiques.

La revue de code est pour moi un moyen de progresser. J’apprends toujours quelque chose à cette occasion, soit pour avoir testé de nouvelles solutions à l’occasion d’une proposition de correctif, soit pour avoir découvert de nouvelles techniques ou manières de faire, auprès d’un collègue de travail.

Quelles sont, selon toi, les meilleures pratiques à suivre ?

Les caractéristiques d’une revue diffèrent en fonction du point de vue à partir duquel on se place. Pour celui qui soumet la revue, l’une des principales difficultés consiste à accepter la remise en question de sa prestation, acceptation inversement proportionnelle à la quantité de travail fournie ou au temps passé. Le plus souvent, cela porte sur des points de détail mais il peut arriver qu’une revue entraîne une refonte importante. L’écart est parfois si large entre l’effet perçu et le produit développé qu’il faut reprendre une grande partie du travail. C’est un des inconvénients du travail en solo car la revue intervient souvent déjà trop tard. La prise en compte des différents points de vue nécessite un refonte qui n’aurait pas eu lieu d’être si les remarques et les aspects critiques avaient été introduits plus tôt dans le processus de développement.

Discuter

Le « reviewer », quant à lui, est en position de faiblesse. En ayant passé moins de temps sur le sujet et moins au courant des particularités fonctionnelles, il ne saisira pas d’emblée la raison de certains détails d’implémentation. De ce fait, il pourra donc à tort faire des retours erronés. C’est pourquoi la revue doit s’accompagner bien souvent d’une discussion pair à pair. Elle permettra de mieux comprendre les choix effectués et d’éviter les quiproquos.

Préciser

Certaines frictions existent lorsque les commentaires portent sur des aspects plus personnels. Comme par exemple le style de développement ou des détails syntaxiques. Il vaut mieux dans ce cas ne pas s’imposer et respecter la personnalité du développeur en se plaçant sous son angle tout en lui proposant quelques axes d’amélioration. La revue a un caractère éminemment pédagogique. A chacun d’objectiver ses choix afin d’éliminer les angles morts, l’imprécision ou le caractère fortuit de certains bouts de code.

Travailler la qualité

L’autre tâche du reviewer consiste à se concentrer sur la qualité de code. Le développeur est concentré sur la résolution du problème, les solutions techniques ou algorithmiques. Il n’est pas forcément focalisé sur le fond et la forme. C’est le rôle du reviewer de le lui rappeler ! Comment améliorer par exemple le découpage fonctionnel, comment simplifier l’implémentation ou les tests unitaires pour les rendre plus lisibles… Ou encore comment améliorer le vocabulaire employé.

Dépasser les blocages

Généralement, tout se fait dans la fluidité et sans anicroche mais il peut y avoir parfois des points de blocage. C’est le cas par exemple lorsque les personnes concernées n’ont pas le même passé, ne viennent pas de la même équipe ou obéissent à des habitudes de programmation difficilement conciliables. Personnellement, j’ai été témoin à plusieurs reprises de ce genre d’impasse. Il en résulte des discussions à n’en plus finir et généralement stériles.
Moi-même, il m’est arrivé d’avoir une explication de fond avec des collègues en raison de divergences de points de vue sur l’utilisation des Mocks dans les tests unitaires. Une réunion d’équipe a été nécessaire pour sortir de l’impasse et adopter une philosophie commune.

S’améliorer

Quoi qu’il en soit, la revue est souvent frustrante pour le relecteur (comme pour le développeur qui la soumet) car on a souvent la sensation, par manque de temps, de concentration ou de volonté, d’être passé à côté de la meilleure solution ou d’avoir omis certains points clés.
Côté développeur ou relecteur, la revue est une occasion de progresser, de recenser les écueils récurrents (« on ne m’y reprendra plus »). Mais c’est aussi et surtout, comme pour l’apprenti musicien vis-à-vis de son mentor, l’occasion de se confronter à un regard extérieur. Et par là-même, d’éviter le « quant à soi » et l’auto-satisfaction, si problématiques en matière de création.

Cet article vous a plu ? Découvrez les autres.