Comment faire une bonne revue de code

La revue de code, en plus de régulièrement sauver un produit d’un défaut de qualité, possède nativement une multitude d’autres vertus. J’en énumère quelques unes ci-après.

486292_3944659706529_1989054166_n

Le Code Review, est-ce ouvert aux Juniors?

Parmi elles se trouve la possibilité de faire monter en compétence les juniors en leur expliquant pourquoi telle façon de faire est mieux qu’une autre.

Dans la même optique, il peut être bon qu’un junior soit reviewer, une vision nouvelle peut parfois apporter énormément à une équipe en place. Seulement, revoir un autre junior a très peu d’intérêt, voire un effet néfaste… J’insiste sur le fait que l’intérêt sera alors de revoir le code d’un senior. L’effet bénéfique supplémentaire est alors un renforcement de la propriété collective du code.

et dans mon Kanban/Scrum board?

Je fais apparaître la colonne Peer Review, c’est un état à part entière avec sa Definition of Done pour passer à l’état suivant. Si on est en Kanban, la WIP (Work In Progress) de la colonne « To Review » doit être généralement très petit par rapport aux autres WIP. En général, on aura un WIP de review qui est inférieur ou égal au nombre de ressources développement divisé par 3.

Comment je me fais « reviewed »?

J’explique le fonctionnement de la fonctionnalité revue: je mets mon reviewer dans le contexte fonctionnel.

Je vais aussi cibler et expliquer particulièrement ce qui est compliqué dans mon code: c’est ça qu’on va chercher à améliorer en premier.

Tout ce que je dois expliquer au reviewer, si on y apporte pas de modification, je considère que je devrai le réexpliquer à chaque personne découvrant le code, donc je dois le documenter.

Comment je fais ma Code Review?

Premièrement, je fais une revue de maintenabilité. Le code doit être compréhensible en 5 minutes.

Puis je demande au développeur ce qui a changé, ce qu’il faut revoir.

Sur du code Legacy, j’applique la règle du boy scout. Le but est de faire rentrer le code dans les standards définis par l’équipe pour le produit. Ainsi, il est très fréquent de modifier du code existant et qu’on n’a pas touché, parce qu’on a écrit du code dans les alentours. C’est vraiment une très bonne pratique à appliquer.

Je fais ma review à côté du ou des développeurs dont je revois le code. Ainsi, les échanges sont temps réel et bien plus fluides. Dans le cas d’équipes non colocalisées, il est tout aussi facile de faire appliquer cette règle, à condition de préciser que la prise de correction d’une review conduit à un arrêt de la production de code sur les autres User Stories. Dans le cas contraire, on aura rapidement une accumulation de travail à reprendre, et les temps de projet vont s’allonger sans limite…

Le seul intérêt sans doute, qu’on peut trouver à faire la revue de code, seul sur son poste, c’est de mettre à l’épreuve la lisibilité du code.

Qui corrige le retour de Review?

Même si ça peut paraître évident, je préfère en parler ici étant donné le nombre de fois où j’ai vu des reviewers prendre la correction directement. A mon sens, la meilleure manière est que ce soit l’auteur du code qui corrige les retours de reviews. Ca permet de s’assurer qu’il y a bien un apprentissage, et une confrontation des visions.

Quel ratio temps de review / temps de développement?

La seule réponse que je puisse donner, c’est qu’il faut calculer ce ratio, le connaître et le maîtriser. Ne cherchez pas à trouver un chiffre ultime, ce ratio va dépendre de chaque projet, sa difficulté technique, le niveau des ressources…

Et de la revue collective?

On en fait aussi. Cela permet d’avoir plus de discussion, plus de confrontation des idées. L’effet bénéfique supplémentaire est une meilleure synchronisation des conventions de codage. Tout le monde apprend.

Nos revues collectives ne durent pas plus d’une heure et on essaie de réunir des groupes d’environ 6 personnes. Au delà de ces limites, la productivité de la réunion baisse en flèche.

Y’a t’il des astuces pour limiter les retours de Review?

Enormément! Certaines idées sont purement managériales. Mais des idées d’organisation portent tout autant leurs fruits.

Travailler en eXtreme Programming sur ses développements: celui qui code parle sans discontinuer, toute ligne de code est expliquée… toutes les 3 minutes, on change de codeur… Même avec un binôme composé d’un senior et d’un junior, le senior va apprendre énormément.

Pour éviter de s’endormir, il est conseillé de se baser sur des Tests Unitaires pour savoir si on a bon ou pas 🙂 Utiliser le debugger va avoir l’effet pernicieux d’endormir celui qui ne code pas (15s sur 4 points d’arrêts et le reviewer pense à autre chose).

A plusieurs reprises, j’ai parlé de review par un senior. Mais qu’y gagne le senior?

Pour le senior, c’est l’occasion d’apprendre à expliquer simplement les concepts pointus qu’il maîtrise sur le bout des doigts. Le junior, en apportant sa vision nouvelle, peut aussi avoir pour effet une correction des mauvaises habitudes du senior. Enfin, la « symbiose » junior + senior peut permettre d’obtenir un bon mélange pour concevoir de nouvelles solutions techniques pointues (regard neuf + expertise à nouveau)

 

Advertisements

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s