La revue de code représente une part importante du travail de tout développeur, mais la faites-vous bien ? Ok, cela pourrait être controversé. Si la revue de code est obligatoire dans votre équipe, je pense que cela cause plus de mal que de bien à long terme selon les contextes.
Il ne s’agit pas d’un argument contre la revue de code en général. Je pense qu’il est indéniable que la pratique de la revue de code présente de nombreux avantages.
Mais si vous ne pouvez pas imaginer votre équipe fonctionner sans revue de code, vous devriez probablement reconsidérer votre approche.
Confiance
La révision obligatoire du code est parfaite pour l’open source. Lorsqu’un groupe d’inconnus apporte des modifications à un projet open source, il est logique d’exiger que toutes les modifications soient approuvées par le responsable. La raison en est qu’il n’y a aucune confiance entre le responsable et la plupart des contributeurs.
Si vous utilisez le même processus de révision du code au sein de votre équipe, qu’en est-il des relations entre les personnes ? L’absence de confiance étant l’un des principaux problèmes des équipes, cela vaut la peine d’y réfléchir un moment.
Fausse confiance
Je ne parlerai pas des problèmes typiques de la revue de code. Discussions inutiles, discussions sur le style, attente trop longue pour la révision… Ces problèmes sont relativement faciles à résoudre. Mais il y a un problème plus important.
La revue de code obligatoire est quelque chose qui peut cacher d’autres problèmes.
Il y a un tas de problèmes dont les conséquences peuvent être atténuées d’une manière ou d’une autre par la révision du code :
- Pas assez de mentorats et certains membres de l’équipe n’ont pas les compétences/connaissances nécessaires pour écrire un code correct et de bonne qualité.
- Une mauvaise planification, qui ne prévoit pas de temps pour une bonne collaboration, la programmation en binôme ou en groupe.
- Pas assez de travail de conception (à ne pas confondre avec le Big Design Up Front) ou un mauvais modèle de domaine.
- Pas de propriété partagée pour le produit.
- Ne pas travailler en petits lots qui peuvent être diffusés en toute sécurité.
- Mauvaises pratiques de déploiement. Pas de moyen de déployer, tester et annuler rapidement et en toute sécurité chaque changement effectué.
- Absence de suite de tests fiable (à ne pas confondre avec une « couverture de test à 100% »).
- Manque d’outils automatisés comme les linters/formateurs, etc.
Le défi
Ce faux sentiment de confiance est l’un des aspects les plus difficiles de la révision du code. En effet, si ces problèmes existent, le fait de ne pas passer par un processus de révision du code peut en fait les mettre en évidence. Si une équipe constate que les choses ont empiré, elle reviendra probablement rapidement à exiger l’approbation de chaque changement.
C’est pourquoi il s’agit d’un sujet controversé. Compte tenu des nombreux avantages de la révision du code et des nombreux exemples concrets de problèmes liés à l’absence de révision du code, il est difficile de croire que c’est la révision du code elle-même qui contribue à certains de ces problèmes.
Travaillez sur les fondamentaux
Si vous ne pouvez pas imaginer travailler sans revue de code, réfléchissez bien à la cause de ce problème. Je pense que nous devrions toujours travailler sur les problèmes sous-jacents et les bons principes fondamentaux, au lieu de traiter les symptômes.
Essayez d’instaurer la confiance, donnez aux membres de votre équipe le temps d’apprendre, améliorez vos processus. Je ne dis pas qu’il faut se débarrasser de la revue de code. Mais la révision du code devrait être une affaire de collaboration et non de vérification.
Quelques idées
Si vous comptez actuellement sur la révision obligatoire du code, je ne vous recommande pas de l’arrêter tout de suite. Mais il y a certaines choses que vous pouvez faire pour que votre équipe s’en remette moins à elle :
- Faites plus de programmation en binôme. C’est un excellent moyen d’instaurer la confiance, de partager la compréhension et la propriété, de partager les connaissances et de recevoir un retour rapide.
- Investissez dans le mentorat. C’est l’un des moyens les plus efficaces de développer les compétences et les connaissances, et c’est une solution gagnante pour le mentor comme pour le mentoré.
- Prévoyez du temps pour l’apprentissage et la recherche dans votre temps de travail.
- Faites de la conception collaborative avant de commencer à travailler sur quelque chose. Des ateliers tels que l’Event Storming ou une session de collaboration rapide devant un tableau blanc peuvent vous aider à trouver la plupart des problèmes potentiels et à gagner beaucoup de temps. Vous pouvez également esquisser vous-même une solution, puis la présenter à votre équipe avant de passer à la mise en œuvre.
- Travaillez par petits lots. Cela raccourcira le cycle de retour d’information et réduira considérablement les risques.
- Essayez d’améliorer votre processus de déploiement et de mise en production. Pouvoir déployer, tester et annuler rapidement chaque changement change la donne. Renseignez-vous sur les drapeaux de fonctionnalités, les déploiements sans temps mort, les déploiements bleu-vert et les déploiements canari.
- Investissez dans une suite de tests fiable, le signalement des bogues, la surveillance et la journalisation. Il est souvent plus important d’être capable de détecter, de déboguer et de corriger rapidement les bogues que de les prévenir (puisque vous ne pouvez pas tous les prévenir).
- Je pense qu’il s’agit là d’actions faciles à mettre en œuvre, à faible coût et sans grand risque. Elles prennent un peu de temps, mais les bénéfices sont rapides (et vraiment durables).
Résumé
La confiance est essentielle pour que les équipes soient performantes. Les processus et les outils peuvent être utiles, mais si nous nous en remettons trop à eux (et ne pouvons imaginer travailler sans eux), c’est toujours le signe de certains problèmes sous-jacents.
J’espère que vous allez essayer certaines des choses que j’ai mentionnées et que vous vous concentrerez sur la mise en place de grands principes fondamentaux pour votre équipe.
Si vous n’êtes pas d’accord avec cet article, n’hésitez pas à me contacter ! J’aimerais beaucoup connaître votre opinion à ce sujet.
