La code-review : tout un art !

La revue de code, c’est compliqué : faire une code-review correctement peut être une tâche assez fastidieuse. Mais il est aussi difficile de la demander, ainsi que de la recevoir ! Dans cet article, nous allons voir comment faire pour que ça se passe le mieux possible, autant pour le « reviewer » (celui qui révise le code), que pour le « reviewé » (celui qui a produit le code).

Demander une code-review

Quand on produit du code, il arrive que l’on ne soit pas sûrs de nous, qu’on ait des doutes sur ce qu’on vient d’écrire, même si ça fonctionne correctement. 🤔 Ou bien, à l’inverse, il arrive qu’on soit vraiment très fiers de nous, parce qu’on a trouvé la solution ultime à un problème complexe. 💪 Dans les deux cas, une petite revue de code par un autre développeur est sûrement nécessaire !

Quand on a des doutes, il est évident qu’avoir l’avis d’un autre développeur est forcément bénéfique afin de nous conforter dans nos choix ou pour nous aiguiller sur une autre solution plus efficace ou plus propre. Mais quand on est sûr de nous, il est toujours bon qu’un autre développeur mette son nez dans notre code, ne serait-ce que pour lui montrer ce dont on est fier 😁, mais aussi (et surtout) parce qu’il y a toujours un risque qu’on ait fait n’importe quoi, embarqué dans notre élan, et qu’on ait pas vu quelque chose d’évident, tant notre enthousiasme était grand. 🚀

Il est important de noter que le reviewer ne doit pas nécessairement être quelqu’un de plus expérimenté que le reviewé. Dans la majorité des cas, le simple fait de ne pas être celui qui a écrit le code permet d’avoir le recul nécessaire à faire une code-review de qualité. De plus, c’est toujours l’occasion d’apprendre de nouvelles choses, pour les deux développeurs impliqués dans le processus ! 🤓

Enfin, il faut bien comprendre que la code-review n’est pas destinée à être un contrôle de la quantité de travail que les autres font, ni même de juger le travail des autres. Il s’agit d’un moyen d’augmenter la qualité de ce qui sera introduit dans la codebase, en réduisant le nombre de bugs introduits, et d’éviter la dette technique. Mais aussi, c’est un formidable outil de formation des développeurs. C’est un échange, pas un procès ! ❤️ Alors n’hésitez pas à demander à vos pairs de reviewer votre code, même si vous pensez avoir un très bon niveau.

En tant que demandeur d’une révision de code, nous avons deux devoirs :

  • Avoir donné le meilleur de nous-même avant de soumettre. Il faut double-checker son travail, pour ne pas demander aux autres de le faire à notre place. Chaque erreur qu’on évite en amont rendra plus simple la tâche du reviewer, qui sera donc plus efficace.
  • Faire des pull-requests les plus petites possible ! En effet, une code review de quelques petits fichiers sera toujours plus sympa à faire, et du coup plus efficiente, qu’un gros paquet de code finissant par lasser et exaspérer le reviewer, qui aura tendance à être moins attentif. Quand ce n’est pas possible, le mieux est de séparer le code dans plusieurs branches et atomiser les implémentations.

Faire une code review

Quand un collègue vous assigne une pull-request, restez calme. Ne paniquez pas, ça va bien se passer. 😌

Tout d’abord, il vaut mieux prévoir de faire ça quand on a terminé une tâche en cours. Il n’est pas bon de s’interrompre pour se lancer tête baissée dans une code-review. Elle sera de moins bonne qualité, car on aura l’impression d’avoir laissé quelque chose en suspens. Et en plus, on perdra du temps lorsqu’il nous faudra retourner à notre occupation précédente ! Chaque chose en son temps. Et le temps d’une code review, dans l’idéal, ne devrait pas dépasser une heure. 🕐 Si c’est le cas, c’est qu’il y a trop de code… Et qu’il faut demander au reviewé d’atomiser en plus petites pull-requests, autant que faire se peut.

De même, il faut être dans un bon état d’esprit, un bon “mood”. Si vous êtes de mauvaise humeur, 😠 laissez tomber et reporter la review à plus tard, ou bien demandez à quelqu’un d’autre de la faire à votre place. Ainsi, vous aurez moins de risque de transmettre vos mauvaises ondes, et de blesser votre collègue par des propos qui vous échappent.

Allez c’est parti 🧑‍🚀 ! Ouvrons notre diff-view favorite pour inspecter tout ça. Que se soit sur Github, dans Gitlab ou chez Bitbucket, cette vue est facile à comprendre : en vert les additions, et en rouge les suppressions. Certains logiciels pour Git disposent aussi de vues en diff, comme Gitkraken ou Tower. Mais les applis en ligne seront plus pratiques pour écrire des commentaires associés à des lignes spécifiques du code source.

Soyons attentifs. 🔍 On prête attention aux noms des variables, aux standards de clean-code qu’on a défini en amont (les principes YAGNI, DRY, etc.), à l’efficacité des routines implémentées, à la présence ou l’absence des tests, aux problèmes éventuels de sécurité ou de performances qui pourraient avoir été introduits, etc.

Et pendant ce temps, surtout, on ne râle pas ! Ronchonner n’amènera rien de constructif à votre review… Sauf si c’est votre manière d’être et que ça vous aide. 🙊 Quoi qu’il en soit, ce qu’il faut éviter, c’est de devenir acariâtre, et d’en vouloir au développeur qui a produit le code qu’on a en face de nous. Partons du principe qu’il a donné le meilleur de lui-même. C’est l’un de ses devoirs. Et l’un des nôtres, c’est de respecter son travail. Au contraire, les encouragements et la bienveillance sont en général bien plus efficaces. Détectons le meilleur de ce qui a été fait, pour mettre en valeur le travail fourni, et faire en sorte que ce genre de bon travail soit la norme. 🧘 Et rappelez vous : nous sommes des humains, pas des scripts !

En tant que reviewer, nous avons donc trois devoirs :

  • Respecter le développeur qui a produit le code. C’est un humain tout comme nous, il a des sentiments, une sensibilité. Ne faisons pas à autrui ce que l’on aimerait pas subir ; restons courtois, utilisons des suggestions plutôt que l’impératif. Adressons nous à l’équipe dans son ensemble : utilisons des phrases comme « si on fait ça… », plutôt que « tu as fait ça… ».
  • Lire et comprendre la totalité du code qu’on doit reviewer, de manière assidue et précise. Ne pas se contenter de survoler le code, et détecter les problèmes éventuels dans les moindres détails. Si on ne comprend pas quelque chose, il ne faut pas s’en cacher mais plutôt demander des explication au développeur.
  • Avoir un rôle formateur. Lorsqu’on soulève un problème, un peu de pédagogie ne fait pas de mal : expliquer pourquoi tel ou tel problème peut survenir, de manière claire, et donner une (ou plusieurs) astuce(s) pour y remédier. Cela fera monter en compétence notre collègue tout en améliorant la qualité du code.

Recevoir une code review

Une fois que le reviewer nous a signalé qu’il avait terminé, il nous faut prendre le temps de corriger. 🖊️ Ici aussi, restons calme, et faisons ça sans interrompre une autre tâche.

Quand on lit les commentaires, il est très facile de se sentir visé. Il s’agit de notre travail, qu’on a pris du temps à faire, de notre mieux ! Et lire des critiques sur ce qu’on a fait n’est jamais facile. Mais pour le bien du code, il faut garder la tête froide… 🥶 Normalement, le reviewer évitera de nous froisser dans ses commentaires, car il jugera le code et non pas nous-mêmes. Mais il se peut qu’il ait lâché au passage une petite pique involontaire, une petite remarque qui nous touche plus profondément. Et c’est là qu’on doit faire preuve de self-control, ne pas partir du principe que son intention était de nous énerver. Pratiquons l’« Egoless Programming » : nous ne sommes pas le code que nous produisons !

Quelquefois, il peut arriver que le reviewer ait tort… Ou du moins, que l’on pense qu’il ait tort. Il peut avoir mal compris notre intention de départ, mal appréhendé un concept, ou avoir loupé une variable dans son analyse. Dans ce cas, il faut répondre au commentaire original en expliquant clairement pourquoi on pense que son raisonnement est erroné, et lui montrer que notre solution est plus adaptée. Mais il faut surtout éviter de rentrer dans des débats et polémiques sans fin… 👺

Enfin, une fois qu’on a apporté toutes les modifications, améliorations et corrections que le reviewer avait souligné, on peut tout à fait lui redemander une petite review de ces corrections, si il y en avait beaucoup ou qu’on a encore des doutes. Ensuite, on peut finalement faire un merge de notre travail dans le tronc commun ! 🎉


Vous avez maintenant toutes les astuces pour faire des code-reviews de qualité, et pour savoir les recevoir. Il ne vous reste plus qu’à la pratiquer avec vos collègues ! Vous verrez que ça fera monter en compétence toute l’équipe au fur et à mesure, et que le produit sur lequel vous travaillez gagnera beaucoup en qualité. 🏆

Si vous rencontrez des difficultés, nous pouvons peut-être vous aider à les surmonter… Chez Pulsanova, nous avons une grande expérience de la revue de code. Alors n’hésitez pas à nous contacter !