En tant que développeur freelance, vous avez certainement déjà été confronté à de la dette technique, à des bugs sur la version de production ou tout simplement à du code incompréhensible. Ces difficultés peuvent entraîner un stress vis-à-vis de la deadline à respecter, et même nuire à votre moral. Saviez-vous qu’il existe une solution pour limiter tous ces problèmes ? Il s’agit de… la revue de code !
Qu’est-ce qu’une revue de code ?
La revue de code (code review en anglais) est l’examen systématique du code source par une tierce personne. Son objectif est de déceler les bugs avant la mise en production, mais aussi d’améliorer la qualité et la sécurité du code.
Wikipédia le compare très justement au comité de lecture, qui intervient dans le processus de publication d’un livre.
Si la revue de code est encore relativement peu implantée dans les entreprises, les choses semblent évoluer. Aujourd’hui, des grands noms tels que Google, Linux ou encore Intel y ont recours.
Pourquoi se lancer dans un code review ?
Procéder à une revue de code systématique offre de nombreux avantages :
- Oblige le développeur à relire ce qu’il vient de coder, et donc à prendre du recul ;
- Permet de limiter fortement le risque de bugs mis en production ;
- Sensibilise toute l’équipe au respect des bonnes pratiques et à la qualité du code ;
- Favorise un code plus lisible et maintenable ;
- Réduit la dette technique ;
- Encourage la tenue à jour de la documentation ;
- Permet la montée en compétences de l’ensemble de l’équipe ;
- Améliore l’implication et la compréhension de chaque développeur dans le projet.
Il n’y a pas d’inconvénient particulier au code review, si ce n’est que cela demande du temps. Temps qui ne sera pas consacré au développement de nouvelles fonctionnalités mais cette perte n’est que temporaire.
Le fait d’avoir un code plus stable et plus compréhensible permet à l’inverse de gagner du temps sur du plus long terme.
D’ailleurs, d’après l’IFSQ, c’est 33 heures de maintenance qui pourraient être évitées avec seulement 1h de review ! Honnêtement cela paraît énorme, mais pour des projets conséquents, subissant une dette technique et des bugs en production, cela doit effectivement pouvoir se vérifier.
Qui est chargé de la revue de code ?
Les responsabilités de chacun dépendent des entreprises. Certaines privilégient les développeurs séniors, voire le lead dev, d’autres leur associent un développeur junior. Chaque solution présente son lot d’avantages et d’inconvénients.
Confier le code review au lead dev
Le lead dev est la personne la plus expérimentée de l’équipe, mais aussi celle qui connaît le mieux le projet. Il semblerait donc logique de lui confier cette mission.
En effet, c’est la personne la plus susceptible de déceler les problèmes le plus rapidement, mais aussi de leur trouver des solutions pertinentes.
Le problème, c’est que toute la connaissance du projet risque alors de reposer sur une seule personne. Si le lead dev s’en va ou est indisponible, des difficultés peuvent rapidement apparaître.
Confier le code review à des développeurs séniors
Confier la revue de code à plusieurs développeurs séniors permet de bénéficier de leurs expertises, tout en partageant les connaissances du projet.
Il n’y a à priori pas de problème particulier avec cette solution, si ce n’est qu’elle met à l’écart les développeurs moins expérimentés.
Confier le code review à des développeurs juniors
Confier le code review à un développeur junior peut sembler être une idée saugrenue, et pourtant ! Cela représente une expérience très enrichissante pour lui car il découvrira de nouvelles façons de faire. Il montera ainsi en compétences plus rapidement.
Bien entendu, se contenter d’une revue de code par un développeur junior est risqué. Il est tout à fait normal qu’il passe à côté de certains détails.
Solution recommandée
Alors que faire ? À qui confier les revues de code ?
Pour ma part, je recommande tout simplement de mélanger les techniques : confier cette mission à un duo de développeurs, à savoir un junior et un sénior.
Pour gagner du temps et optimiser la formation, cette opération peut se faire en pair programming (2 sur le même ordinateur).
Vous pouvez également régulièrement changer de duo afin que toute l’équipe soit impliquée dans la qualité du projet, et monte en compétences.
Le lead dev peut faire une seconde vérification, mais attention : la double validation est plus chronophage.
Comment faire une revue de code ?
Il existe plusieurs manières de mettre en place une revue de code :
Utiliser les pull request / merge request
Les solutions de versionning se sont grandement démocratisées au cours de ces dernières années. Aujourd’hui Github, Gitlab et Bitbucket sont devenus des incontournables pour les développeurs.
Le versionning permet de créer des « branches » de travail sur un même projet. Ainsi, plusieurs développeurs peuvent travailler en même temps sur des versions différentes d’un projet, sans se gêner l’un l’autre.
Lorsqu’un développeur est satisfait de son travail, il ouvre un pull request (sur Github et Bitbucket) ou une merge request (sur Gitlab).
La personne chargée de la relecture peut alors valider le code avant de le merger, c’est-à-dire avant de l’implanter sur la version principale du projet.
En cas de problème avec le code, le relecteur peut refuser la merge/pull request, sans que cela n’ait de conséquences pour le reste de l’équipe. Il indique alors, grâce à un système de commentaires, tous les points à rectifier. Le développeur peut de nouveau soumettre sa version lorsqu’il a réglé lesdits problèmes.
Cette méthode de code review est à mon sens la plus pratique et la plus fluide de toutes. C’est celle que je vous recommande.
Utiliser un logiciel spécifique
Il existe également des logiciels spécifiques pour réaliser un code review. Ils facilitent également l’audit de code source. En voici une liste non exhaustive :
Si vous en utilisez d’autres, ou si vous avez des avis sur ces outils, n’hésitez pas à poster un commentaire 🙂
Autres méthodes
D’autres solutions existent pour effectuer des revues de code. Je les trouve toutefois moins pratiques et moins faciles à mettre en place que la technique du merge request évoqué plus haut.
Voici quelques exemples :
- L’inspection formelle ;
- La notification par email ;
- L’analyse par-dessus l’épaule ;
- La programmation en binôme (pair programming).
6 conseils pour une code review réussie
Vous désirez mettre en place des revues de code systématiques pour votre projet ? Félicitations ! Voici quelques conseils pour bien les réussir :
1# Place à la bienveillance !
L’un des principaux problèmes de la revue de code c’est… l’ego des développeurs. C’est humain, personne n’aime particulièrement que son travail soit analysé et critiqué.
Aussi, lors de votre code review, assurez-vous d’être le plus bienveillant possible :
- Pas de moquerie ou de critique envers le développeur ;
- Dîtes les choses gentiment ;
- Essayez autant que possible de proposer des solutions lorsque vous mettez le doigt sur un point dérangeant ;
- N’ayez pas peur de souligner les choses positives (pas forcément dans les commentaires pour ne pas noyer le reste, cela peut se faire à l’oral, via Slack ou tout autre outil de communication) ;
- Évitez l’impératif dans vos commentaires ;
- Préférez les pronoms « nous », « on » ou même « le code », plutôt que « tu ». Exemple « le code pourrait… » plutôt que « tu devrais… ».
La revue de code n’est pas du dev-bashing !
Et à l’inverse, lorsque votre code est relu par un autre développeur, ne prenez pas les critiques personnellement.
Tout le monde fait des erreurs. Personne n’a la science infuse. Et c’est justement en travaillant ensemble, en bonne intelligence, que l’on progresse.
2# Retirer le respect des standards de la revue de code
Deuxième conseil : lors d’un code review, ne regardez que le fond et non la forme.
Rien de pire qu’une review avec des dizaines de commentaires pour cause d’accolade au mauvais endroit, d’espace manquant ou autres… Non seulement cela peut décourager le développeur, mais en plus cela noie les retours pertinents.
À la place, je vous recommande d’établir une charte de bonnes pratiques, puis d’automatiser le respect du styleguide. Vous pouvez par exemple utiliser php cs fixer pour cela.
Ainsi, le code source reste cohérent et uniforme quel que soit son auteur. Et vous gagnez en rapidité et en efficacité lors des revues de code.
3# Procéder à une « auto-revue » avant de demander une relecture
Avant de lancer un pull/merge request, prenez l’habitude de relire calmement votre propre code. En d’autres termes, de faire une « auto review ».
Vous veillerez ainsi à ne laisser passer aucun bug ou erreur d’inattention, à commenter votre code et à vous assurer de sa qualité (refactoring notamment).
Car oui, le risque d’une revue de code systématique c’est que les développeurs se dédouanent de leurs responsabilités. Comme ils savent que leur code va être corrigé par un autre, certains peuvent en profiter pour se reposer sur eux.
Par respect pour vos collègues, ne faites pas cette erreur. Ayez à cœur de fournir du travail de qualité, et faites-leur gagner du temps !
À titre personnel, j’essaye de me fixer la règle suivante : je ne fais de merge request que quand j’estime que mon code peut être mis tel quel en production. Si ce n’est pas le cas, alors c’est que je peux encore l’améliorer.
4# Privilégier les petites revues
Veillez en outre à faire les commits les plus petits possibles.
Gardez à l’esprit qu’une branche = un bug (ou une feature), et un seul seulement !
Non seulement cela réduit les risques, mais en plus cela fait économiser beaucoup de temps lors de la revue. Il n’est en effet jamais agréable de devoir relire des centaines ou milliers de lignes de code, réparties dans des dizaines de fichiers différents… Sans parler du fait qu’on risque de passer à côté de quelque chose d’important !
5# Expliciter les commits
Tant qu’on évoque les commits, assurez-vous également de toujours leur donner un titre explicite. Non « Fix » ou « Ajout de feature » ne sont pas des titres explicites.
Le relecteur a besoin de savoir ce dont il s’agit pour être efficace.
D’ailleurs, si vous prévoyez d’écrire trop de choses dans le nom de votre commit, c’est sans doute qu’il est trop gros !
6# Intégrer les revues de code dans le planning
Enfin, dernier conseil et non des moindres : intégrez-les dans le planning de développement !
Sinon, plus la deadline approchera et plus les revues de code seront bâclées (voire passeront à la trappe). Non seulement cela pourrait créer de la dette technique, mais en plus vous risquerez de laisser passer des bugs en production.
Astuce : en plus du temps alloué aux revues de code elles-mêmes, prévoyez également des créneaux pour les corrections qui en résultent !
Aller plus loin
Pour gagner encore davantage en efficacité, la revue de code est idéalement accompagnée d’autres process :
- Les tests unitaires ;
- Les tests fonctionnels ;
- Les tests de performance ;
- La génération de la documentation technique ;
- Les vérifications de conformité au styleguide.
Chacun d’entre eux pourra être automatisé pour une intégration continue réussie.
Et vous, vous en faites des revues de code ? Pourquoi ? Dites-nous tout en commentaire !
