Parmi les bonnes pratiques auxquelles nous sommes très tôt confrontés dans sa carrière de développeur, la code review est sans doute une des plus importante. On la retrouve dans (presque) toutes les entreprises, pourtant personne ne la fait deux fois de la même façon. C’est un rituel nécessaire, mais nulle part il est documenté. Au final, qu’est-ce qu’on attend de la code review?
Bien qu’on illustre souvent le travail d’un développeur à celui d’un métier du bâtiment, celui-ci ressemble plus à un travail d’écrivain ou de journaliste. En effet, un carreleur apprend son métier puis l’applique, chantier après chantier. La technique appliquée et le fruit de son travail seront dans un état final. Il n’y aura pas de « refactor » du carrelage.
En revanche, un développeur travail sur un produit – la codebase – vivant. Elle va évoluer en fonction des besoins utilisateurs, des technologies disponibles, de l’infrastructure à disposition. Par conséquent un développeur, en plus de son expertise, doit faire preuve de créativité dans son travail. Comme ce travail mêlant technique et créativité est mentalement très exigeant, faire une code review par un autre développeur va permettre une amélioration systématique de la qualité du code produit.
La Code Review est un gage de qualité
Mine de rien, la charge mentale pour un développeur est conséquente. On doit en permanence avoir à l’esprit les différents contextes, les règles métiers, les potentielles implications entre les différentes briques, le tout en produisant du code propre, documenté et testé. Après tout nous sommes humains et nous avons aussi nos moments de fatigue ou d’inattention. Plus la codebase grandie, plus le système se complexifie, plus il est difficile de maintenir le standard de qualité du code.
C’est un problème qui se reflète également dans l’aéronautique. Pour pouvoir avoir des avions qui volent de plus en plus loin et transportent de plus en plus de passagers, il a fallu créer des systèmes de pilotage complexes. Parce que ces systèmes sont devenu aussi développés, il n’était plus possible pour un seul pilote d’assurer son travail de manière durable. C’est pourquoi il y a maintenant dans les cockpits un pilote et un co-pilote, ayant chacun accès aux mêmes manettes de contrôles. Suivant les tâches, l’un des deux va l’accomplir et le second va vérifier que celle-ci a été correctement accomplie.
Dans le développement, le comportement recherché dans la mise en place de code reviews. En augmentant le nombre de paire de yeux par lesquels un morceau de code doit passer, on réduit les chances d’insérer dans la codebase une dette technique, à savoir du code qui ne serait pas optimisé, qui serait difficile à interpréter ou qui est redondant.
Un filet de sécurité contre les bugs à venir
Suivant une étude faite par Codacy qui a interrogé plus de 600 développeurs, l’implémentation de la code review a permis aux équipes de passer en moyenne 4h de moins par semaine à débugger et autant de temps en plus à travailler sur de nouvelles fonctionnalités.
Parfois le code produit aura beau passer les tests mais il introduira un comportement non désiré (et non testé). Dans ces cas-là, l’expérience des développeurs seniors et de ceux qui ont une bonne connaissance du système et des règles métier pourront prévenir ces erreurs. Il est pertinent d’écrire un test unitaire ou fonctionnel qui met en relief ce potentiel effet de bord, de façon que le code à venir soit protégé d’une régression.
L’apprentissage lors de la code review
Transmission de la connaissance métier
Il n’est pas toujours facile de comprendre, et de retenir, l’ensemble des règles métier qu’abritent une codebase. On a beau avoir codé soit même certaines fonctionnalités, je vous garantis que quelque mois plus tard vous pourriez oublier qu’elles existent. Imaginez la complexité pour un développeur qui démarre sur le projet.
Les code reviews sont de bons moments pour l’auteur du code d’expliquer pourquoi il a passé du temps à travailler dessus. En pratique, les code reviews sont effectuées sur Github, Gitlab ou Bitbucket. Au moment de l’ouverture de la Pull Request qui donnera lieu à la code review, il est bien de préciser pourquoi ce code existe. Il est également possible de
Transmission de la connaissance technique
La code review est aussi un bon moment pour bénéficier d’une transmission de compétences techniques. En tant que développeur junior, ou même confirmé, il peut arriver que vous ayez à faire une code review sur un block que vous ne comprenez pas. Vous n’êtes peut-être pas encore famillier avec ces briques techniques et ce n’est pas grave. À ce stade, votre rôle est de passer en revue le code à la recherche de duplications, à évaluer le nom des variables et des fonctions, à voir s’il n’y a pas intérêt à diviser une fonction en deux par exemple.
Par contre, c’est également le moment de poser la question, sur la brique que vous ne comprenez pas, à votre équipe. Que ce soit par messagerie, de vive voix où même documenté dans la Pull Request (ou Merge Request sur Gitlab).
Les limites de la code review
Les règles syntaxiques sont à automatiser
Les pratiques syntaxiques comme mettre un point-virgule à la fin de ligne ou utiliser les ‘simples quotes’ au lieu de « double quotes » doivent être vérifiés automatiquement par un Linter. Cette vérification pouvant être automatisée, c’est une charge mentale de moins sur les épaules des développeurs.
Attention aux Code Reviews trop longues
L’attention des collègues est compliquée à avoir. Pour faciliter leur travail dans la revue de votre code, une bonne pratique est de faire des Pull Requests ayant peu de changements à la fois. Si vous travaillez sur une fonctionnalité générant beaucoup de changements, n’hésitez pas à ouvrir votre PR avant d’avoir terminé, pour faire valider votre code étape par étape et non pas avoir 42 fichiers modifiés à faire valider, ce qui rend le travail beaucoup plus pénible pour les Reviewers.
Adaptez le nombre de revues minimum
Ajouter une deuxième paire d’yeux sur une codebase apporte de nombreux bénéfices. Par contre, en ajouter une troisième paire en apporte, mais moins. Si vous augmentez trop le nombre de revues minimum avant de valider une Pull Request, le processus de validation, et donc de déploiement, devient plus long. De plus, plus il y a de développeurs à revoir le code, moins les revues sont faites consciencieusement.
Tout le monde ne peut pas faire la review
Seuls ceux qui n’ont pas participé au code peuvent faire une code review. En effet, si un junior a commencé à développer le code, puis s’est fait assister par un collègue pour terminer, ce dernier ne pourra pas faire la code review car il en est partiellement l’auteur. Donc là aussi, pensez à prendre ce paramètre en compte lorsque vous configurerez le nombre de reviews nécessaire à la validation.
