La revue de code ( “code review” en anglais) est une pratique qui se développe de plus en plus au sein des équipes techniques. Ce n’est pas si facile à adopter sans savoir où l’on va mais surtout quels bénéfice on peut en tirer.
Beaucoup de développeurs connaissent déjà cette pratique sous la forme d’une réunion (une de plus) où les développeurs relisent du code qui à été imprimé. Le but étant en général de trouver des bugs, s’assurer que les bonnes pratiques de développement sont suivie, etc. Cette façon de faire est fastidieuse, demande beaucoup de temps et n’est pas facile à gérer sur le long terme. Elle peut aussi s’avérer intimidante pour le développeur dont le code est relu.
Il existe des outils qui peuvent aider à rendre les revues de code plus facile, intéressantes et donc à en tirer plus de profit. L’un de ces outils est Crucible, de l’éditeur Atlassian.
Quoi de mieux que d’apprendre de l’éditeur lui-même les bonnes pratiques de la revue de code. Giancarlo Lionetti a posté récemment un article décrivant comment l’équipe de développement de Bamboo (un autre outil Atlassian) utilise Crucible pour ses revue de code.
Il y décrit comment Crucible peut aider à revoir:
- du code avant la soumission en système de gestion des versions grâce au chargement de ‘patch‘ ou directement depuis votre outil de développement intégré,
- du code une fois dans le système de gestion des versions,
- des bouts de code, copiés/collés rapidement de façon très informelle,
- des ensembles de changement de code au travers de discussions associées à la soumission des-dits changements.
Je sais que la question que vous vous posez toujours est: mais quels sont les bénéfices de la revue de code? Voici les raisons pour lesquelles l’équipe Bamboo le fait, dans l’ordre:
- Tout le monde est au courant du code soumis en système de gestion des versions. De cette manière tout le monde est à jour avec les derniers changements.
- Apprendre du code développé par d’autres développeurs de l’équipe,
- Savoir ce qu’il se passe autour du code Bamboo (de votre projet),
- Réduire les moments “P*** qu’est-ce qui se passe…?!”, la maintenance ne devrait pas être la première fois qu’un développeur voit le code,
- Être sûr que le code fonctionne.
L’ordre peut paraître étrange. Mais les revues de code sont avant tout un moyen pour les développeurs de communiquer, de garder le contact avec des parties du code sur lesquels ils n’ont pas forcément encore travaillé. Trouver des bugs et s’assurer que le code fonctionne est la responsabilité principale du développeur qui à développé le code en question, pas celle de l’équipe toute entière.
Pour que ces revues soit efficaces il nous propose quelques trucs:
- faire de petites revues, avec peu de changements,
- avant de créer votre revue, revoyez votre code vous même,
- créer des revues cohérentes, par exemple ne créez pas de revues avec deux développements différents, un seul à la fois,
- commentez vous même votre revue, expliquer pourquoi vous avez fait tel ou tel changements, poser les questions que vous avez à propos de votre propre code, etc.
Je vous invite vivement à lire la version originale (en anglais) de cet article sur le blog d’Atlassian qui n’est qu’une première partie…
