Principes et avantages de la revue de code

Parmi les différentes démarches qualité mises en place chez Novaway, la revue de code est l’une des plus ancrées dans nos process.

La revue, qu’est-ce que c’est ?

La revue de code (code review en anglais) est une relecture d’un morceau de code avant son ajout au code source global d’une application ou d'une plateforme web. Cette relecture vise, entre autres, à valider que les bonnes pratiques de développement ont bien été respectées et à détecter les potentielles faiblesses d’architecture, l’oubli de “code mort”, etc. 

Qui utilise la revue de code ?

La revue de code est une pratique assez répandue dans le développement. Cette pratique peut être mise en place quelle que soit la taille des équipes. Plusieurs grands noms ont mis en place une politique de revue de code, par exemple :

• Google, avec une politique très précise
• Cisco
• Intel
• Nasa
• Novaway ;)

La revue de code en chiffres

33 : c’est le nombre d’heures de maintenance que permet d’économiser une heure de revue (selon ifsq.org - source)

60% : c’est la quantité moyenne de bugs détectée par la revue de code (contre 25% par les tests unitaires et 45% par les tests d’intégrations, qui ne sont pas pour autant à négliger car ils ont d’autres vertus : non-régression, documentation vivante…) (source)

Les avantages de la revue de code

Avoir une politique de revue de code performante demande du temps et peut, de prime abord, semblez être un coût inutile. Pourtant, elle offre de nombreux avantages, certains visibles directement et d’autres plus latents :

• La qualité du code est évidemment améliorée, il devient plus maintenable, mieux architecturé
• Le nombre de bugs est réduit
• La communication et la collaboration entre les membres de l’équipe sont accentuées
• La lecture de code a un aspect formateur sur l’équipe projet
• La connaissance du projet est correctement ventilée sur l’ensemble de l’équipe

Les bonnes pratiques demandeur et relecteur

Mettre en place une politique de revue de code, c’est bien, mais une revue de code mal implémentée peut devenir un poids plus qu’un bénéfice. Chacun a sa responsabilité dans la réussite d’une bonne revue, le demandeur comme le relecteur.

En tant que demandeur

• Restez atomique. On a tendance à dire qu’une revue de 100 lignes est faite en 15 minutes, une revue de 1000 lignes en 5 minutes.
• Expliquez le Pourquoi. La description d’une revue ne sert pas à dire ce qui a été modifié (le code le fait déjà) mais l’intention derrière cette modification.
• Soyez explicites. Le relecteur aime savoir à quoi s’attendre. Il n’y a rien de plus frustrant qu’une demande de revue intitulée “Fixes” (le pluriel indique d’ailleurs que la revue n’est pas atomique).
• Faites une auto-revue avant de l’assigner, cela permet notamment de réduire les retours liés au messages de debug oubliés, au code commenté… n’hésitez pas à commenter certains aspects du code pour donner du contexte au relecteur.
• Respectez les standards. Votre réflecteur saura vous remercier de faire la revue d'un code dont la structure est familière. Cela lui permet aussi de se focaliser sur le fond plus que la forme.
• Soyez responsable. La relecture de votre code ne vous dédouane pas de sa qualité, vous en êtes toujours responsable.

En tant que relecteur

• Soyez bienveillant
• Ne cherchez pas la petite bête, mais visez surtout l’amélioration de la structure du code
• Soyez bienveillant
• Concentrez vous sur le fond, ou faites comme Google avec un relecteur “fond” et un relecteur “forme”
• Soyez bienveillant
• Incitez à la réflexion commune plutôt que de donner des solutions toutes faites
• Soyez bienveillant
• Distinguez bien les suggestions des modifications nécessaires, surtout quand les deadlines sont rapprochées

Les outils

Si vous faites votre contrôle de code source avec Git, la plupart des outils de collaboration (Github, Gitlab, Bitbucket … ) proposent par défaut une revue de code lors de la création de Pull Request / Merge Request. Il existe d’autres outils plus indépendants, avec différentes options, à différents tarifs.

Pour conclure

Même si de prime abord la mise en place de revue de code peut sembler être un coût, le retour sur investissement n’est pas négligeable, autant pour la qualité du code que pour le niveau de l’équipe.

Pour aller plus loin

Tu n’es pas ton code !
http://gb-prod.fr/2016/12/01/la-revue-de-code-bienveillante.html  (video)
http://blog.octo.com/comment-rater-vos-revues-de-code-episode-1/
http://blog.octo.com/comment-rater-vos-revues-de-code-episode-2/
http://blog.octo.com/comment-rater-vos-revues-de-code-episode-3/