Table des matières
Ouvrir table des matières
Revue de code
Comment se fait-il que l’on n’ait pas pu détecter ce bug avant ?
Cette partie code est très obscure, ça a l’air de fonctionner je ne préfère pas y toucher
C’est notre projet historique ! Je suis le seul à avoir la connaissance de celui-ci et je vais t’expliquer son fonctionnement. Prépare-toi au mal de crâne !
Si vous vous retrouvez dans ces affirmations, il est alors temps pour vous de vous mettre à la revue de code.
Mais qu’est ce que c’est exactement la revue de code (ou Code Review en anglais) ?
C’est tout simplement une méthodologie de développement visant à améliorer la qualité du code que vous produisez, et bien plus encore comme nous allons le voir.
Le principe est assez simple : vous soumettez du code que l’on a écrit pour relecture à un ou plusieurs autres développeurs afin de le faire valider.
Pourquoi faire des revues de code ?
Comment cela se passe quand vous codez une nouvelle fonctionnalité ?
Vous avez la « tête dans le guidon » ! Vous codez, vous testez, vous codez, vous testez, etc. jusqu’à ce que cela fonctionne. Et comme ça fonctionne, vous ne prenez pas forcément du recul sur ce que vous venez de produire et vous passez à la fonctionnalité suivante et ainsi de suite. Car oui, pourquoi prendre du recul finalement ? Ce que vous venez de coder fonctionne.
Mais si on vous disait que quelqu’un allait relire ce que vous avez codé pour le commenter et vous dire ce qu’il en pense ? Vous auriez peut être peur du jugement et vous voudriez faire bonne impression auprès de cette personne non ?
N’allez-vous pas vous forcer à relire votre code après avoir fini et améliorer ce qui vous semble améliorable ?
Faire des revues de code va vous permettre entre autres de remédier à cela en vous donnant un bon état d’esprit de collaboration, mais va surtout contribuer à faire évoluer de manière qualitative tout l’environnement de développement (l’équipe comme le projet).
Comment cela se passe une revue de code ?
En règle générale, vous avez ce qu’on pourrait appeler le « demandeur » (celui qui a fait le code et qui demande une revue) et il y a le « relecteur ».
Bien entendu, il peut y avoir plusieurs demandeurs et plusieurs relecteurs pour une même revue de code.
Par exemple où je travaille la mise en production du code est soumis à 2 relecteurs différents tandis que la phase de développement est soumise à un seul relecteur.
En général, le relecteur est un développeur assez expérimenté, car il aura l’oeil pour voir les choses qui pourraient clocher et les diverses améliorations à apporter.
Mais un développeur junior peut très bien faire une revue de code (ce qui sera très bénéfique pour lui car il découvrira d’autres façons de faire).
Le relecteur va analyser le code produit techniquement, mais également voir si cela respecte le cahier des charges de la fonctionnalité.
S’il ne comprend pas quelque chose, il en profitera pour poser des questions et éventuellement proposer une autre solution qui sera mieux comprise, car il pourra apporter une autre vision de la fonctionnalité et surtout un regard neuf.
En se basant sur ses compétences et son expérience, il va pouvoir valider ce qui a été effectué, mais aussi suggérer des modifications plus sécurisées, plus efficaces ou performantes et éventuellement mieux écrites ainsi que mettre en doute une partie de code.
Il pourra lui même apprendre de nouvelles façons de faire qu’il ne connaissait pas auparavant. Et vice-versa pour le demandeur.
Les règles à respecter pour que votre revue de code soit agréable
Il y a, selon moi, des règles à respecter pour faire une bonne revue de code et cela passe notamment sur le comportement humain.
Une revue de code n’est pas un prétexte pour commencer à juger et critiquer négativement le demandeur. Chaque développeur a une expérience, un niveau et une façon de faire.
Donc, ne vous moquez pas de quelque chose qui vous semble bizarre au premier abord. Il y a certainement une raison à cela ou c’est tout simplement une façon de faire que vous ne connaissez pas.
Si vous devez critiquer une partie de code, faites-le avec tact et de manière constructive. Vous devez vous ménager dans votre approche pour ne pas blesser le demandeur et ne pas le frustrer.
Il faut que vous gardiez toujours en tête que vous êtes une équipe et que la revue de code est là pour vous faire progresser ensemble.
Enfin, faites un effort pour faire en sorte que votre revue de code concerne une fonctionnalité et pas un mélange de fonctionnalité.
Il est toujours plus simple et plus efficace de faire la revue d’une fonctionnalité à la fois. Donc si vous utilisez Git, retenez bien cela : une fonctionnalité ou un bug = une branche = une revue de code.
Les avantages d’une revue de code
J’en ai parlé un peu plus haut, mais je vous remets synthétiquement la liste :
- Réduction de bug
- Monter en compétence du demandeur et/ou du relecteur : chacun apporte son savoir et ses compétences à l’autre
- Passage et partage de connaissance sur le projet de manière régulière et intuitive
- Meilleure communication d’équipe
- Meilleur partage de connaissance
- Amélioration de la lisibilité et la maintenabilité du code source
Et quels sont les outils pour réaliser une revue de code ?
Pour ma part où je travaille nous hébergeons le code source de nos clients sur Github 🔗 en dépôt privé et nous utilisons le système de « Pull Request » pour faire nos revues de code à ce moment-là.
Il est possible de les faire directement depuis votre IDE en leur ajoutant la fonctionnalité.
Vous pouvez également vous passer d’outils et vous mettre à deux devant un ordinateur et faire la revue de code en direct. Mais il est parfois difficile que les 2 personnes soient toutes les 2 disponibles, là ou les autres outils permettent de réaliser la revue de manière asynchrone.
Une dernière chose
Oui, la revue de code ça prend du temps. Et ça peut paraître ennuyeux, mais au vu des avantages que j’ai cités plus haut et des problèmes que cela peut vous éviter par la suite, c’est un bon investissement en temps et pour le bon déroulement de votre projet sur le long terme. Et je parle en connaissance de cause.
