Pourquoi la revue de code, c’est le bien
Ou pourquoi la revue de code est une étape absolument nécessaire et comment la mettre en place
A quoi sert vraiment une revue de code ?
Si l’on croit la plupart des articles sur le sujet, la revue de code est sensé “permettre de détecter les défauts dans le processus de développement le plus en amont possible” et donc limiter le risque de bug.
Concrètement, je trouve que c’est un résumé réducteur, j’y vois plutôt ces deux objectifs :
- Vérifier qu’une tâche développée ne contient pas d’erreur de logique, qu’elle est relativement optimale (ou en tout cas pas inutilement complexe) et que tous les cas d’utilisation ont été implémentés
- S’assurer que le code sera compréhensif et maintenable (donc correctement écrit ou documenté lorsque nécessaire, avec des variables et méthodes aux noms intelligibles, ect)
Pour le premier point, les tests unitaires sont censés déjà remplir cette fonction; il faut bien cependant que quelqu’un vérifie, a minima :
que les tests sont bien écrit
qu’ils ne font pas que bêtement appeler du code pour augmenter la couverture / que les assertions sont pertinentes
qu’ils prennent en compte les cas aux limites, etc.
Pour le second point, c’est déjà plus relatif… mais la finalité est de comprendre ce que fait le code le plus rapidement possible, sans avoir à demander à celui qui l’a écrit (auquel cas il faut, de facto, le notifier pendant la revue)
Et bien évidement le code doit être sans redondance, le plus homogène possible avec le reste de l’application (pas deux termes différents pour parler de la même chose) et doit être refactoré si besoin, selon le temps disponible pour cela.
De plus, en dehors de ces objectifs, la relecture de son code par un tiers reste évidement un excellent moyen de vérifier que l’on a pas commis des erreurs d'inattention basique ; et c’est aussi le meilleur accompagnement à donner à quelqu’un qui arrive sur un projet pour qu’il monte en compétence !
C’est également une formidable aide à la cohésion d’équipe, surtout entre développeurs ne se connaissant pas / n’ayant pas travaillé ensemble et un outil d’amélioration continue !
Comment faire du code review
Avec des outils comme gitHub, gitLab ou encore bitBucket, il est très simple de mettre en place des demandes de relectures de code avant validation (pull request chez gitHub & bitBucket), plus besoin donc d’aller lire le code de quelqu’un par dessus son épaule et surtout, les ajouts, suppressions et modifications sont affichées de manière intelligible !
Pour aller avec l’outillage, il faut la méthodologie qui sied bien : avec git, le plus simple reste sans doute de faire du git flow, et de ne merger les branches qu’à la validation du code review.
La taille de l’équipe et son organisation importe également énormément ! La revue de code va prendre du temps et demander de la concentration pour être efficace, et même si, idéalement, tout le monde devrait relire le code des autres et l'approuver à l’unanimité, c’est bien souvent impossible au delà de 3 développeurs sur un projet… 2 relecteurs par demande semble être le meilleur compromis.
Bien entendu, les revues de code doivent être faites dans un délai raisonnable après la publication d’une demande de relecture, et ne pas s’empiler (le stock, c’est le mal)
Pour une revue de code plus efficace, il convient d’avoir un template contenant une checklist de point critiques à vérifier :
Si le développement implique du front, poster une capture d’écran
Si un ajout/modification de base est faite, la documentation doit être mise à jour
Avoir un lien vers le ticket de la tâche à réaliser (jira, trello, bugzilla, mantis...)
Comment relire / proposer une amélioration ?
Avant de relire, il faut connaitre la description de la feature derrière le code, il est donc indispensable d’avoir un lien vers le ticket concerné.
L’outil de revue de code doit permettre l’ajout de commentaire, c’est indispensable. Ceux-ci se doivent d’être le plus clair possible, sans quoi le développeur va perdre du temps à essayer de comprendre ce qui ne va pas; il ne faut donc pas hésiter en cas de doute à relire le code directement avec le développeur qui l’a initié, cela est parfois plus rapide et efficace que d’écrire des remarques incompréhensibles pour autrui.
Basiquement, il faut, avec le besoin en tête, regarder les modifications de code et voir si on les comprend et si elles sembles pertinentes.
En cas d’incompréhesion, faire un commentaire en proposant un autre nom / une autre façon de faire
Si le code est clair mais qu’il pourrait être amélioré, proposer un code plus optimal, et si possible en exprimant le niveau de criticité (par exemple : si tu as le temps, fais ceci... versus ton code va générer des fuites mémoires vu les volumes attentdus, fais plutôt comme cela...)
