Réflexion sur la Revue de code

Aujourd'hui je vais parler de la terreur des programmeurs solitaires. La revue de code. Est-ce que cette pratique est vraiment utile ? Est-ce qu'il y a des bonnes pratiques ? Comment réagissent les employés ? Je ferai donc une petite réflexion sur le sujet.

Définition

La revue de code, c'est lorsqu'une 2e personne révise un code source, un document ou un courriel. Ceci peut-être fait directement sur le poste de l'auteur, en différé ou durant un réunion sur le sujet. La 2e personne doit simplement valider qu'aucune erreur ne soit présente avant de diffuser l'information.

Est-ce que ceci est vraiment utile

En fait, la revue de code est basée sur le Principe de Pareto. Ce principe indique que si ont effectue 20% des efforts, on peut déceler 80% des problèmes. Donc, si une personne revise le livrable rapidement, il risque de résoudre 80% des problèmes qui auraient été rencontrés sinon.

Le but de la revue de code n'est pas d'exclure toute possibilité d'erreur. En programmation, on a les tests unitaires, les tests de fréquence et les tests de convivialité pour résoudre presque 100% des problèmes. Le revu est de détecter le maximum en le minimum de temps. En fait, le concept de programmation eXtreme Programming ou XP est basé sur la revue de code. Donc oui l'utilité est bien présente.

Les bonnes pratiques

Pour débuter, ceci n'est que 4 pratiques. Il doit sûrement en avoir plusieurs autres, mais ce sont les 4 que j'ai déjà utilisés.

Sur le poste de l'auteur

J'aime bien cette revue de code, qui est simplement de demander à une personne de revalider sur son ordi notre travail ou à travers une connexion à distance. C'est simple, ne coûte rien, ne demande pas d'infrastructure et ne demande aucun temps de préparation. Et c'est une revue de code qui est tout aussi efficace. Cette revue permet une très grande interaction entre les 2 personnes, par contre ceci demande aussi que les 2 personnes soient libres au même moment. Du point de vue du gestionnaire de projet, il doit simplement prévoir ce temps de travail comme étant une tâche récurrente qui prend entre 5 à 20% du temps de la tâche principale.

En différé

Le classique d'envoyer nos fichiers par courriel à un collègue pour qu'il les valide. Personnellement, bien que fonctionnel, c'est quand même moins efficace que la revu sur le poste de travail. Par contre, les 2 personnes n'ont pas à être libres au même moment, ce qui permet de plus facilement faire la revue.

Lors d'une réunion

Le top du top de la revue de code. Prévoir un temps que l'équipe au complet fasse la revue. Cette méthode permet de dépasser le 80% des résultats et atteindre presque le 100%. Par contre, gare aux insultes et aux rabaissements gratuits. Il faut être très discipliné pour ce faire et avoir comme matériel une grande télévision ou un projecteur.

Personnellement, j'organisais une revue de code sur une récurrence hebdomadaire. La revue n'était pas sur un code bien précis, mais sur un module. Ceci est tout aussi efficace et évite de jouer sur le morale d'une seule personne.

Avec un logiciel de revue de code

Je dois avouer que j'en ai seulement utilisé un seul, donc je vais me baser sur celui-ci. J'utilise CodeReviewer de la compagnie SmartBear. Il est gratuit, facile à mettre en place, une grande communauté avec des extensions et peut très bien faire la revu de tout ce qui est texte: Code, document ... On possède la flexibilité de la revue différée, mais en conservant le facteur de communication. En bonus, on peut conserver aussi l'historique des revues pour consultation future.

La réaction des employés

Il y a 2 réactions possibles. Ceux qui sont totalement d'accord avec la revue de code, donc je ne parlerai pas d'eux, et ceux qui n'aiment pas se faire critiquer. C'est ici qu'un bon gestionnaire fera la différence. S'il impose la revue de code, vous finirez par avoir une baisse du moral de ces employés. Par contre, s'il implique les employés dans la décision de la revue de code. Comme débuté avec une réunion de module au lieu d'une revue spécifique à une personne. Ces personnes ne se sentiront pas attaquer par les critiques, puisque les critiques ne seront pas sur leur travail précisément, mais sur le travail du groupe. Ensuite, vous pouvez encourager des revues sur le poste de travail pour les sections plus complexes. Et finalement, installer un logiciel de revu. Puisque la transition sera graduelle et non imposée, vous risquez de voir moins de réticence. Mais de grâce, la revu prend du temps, il faut le donner aux employés, puisque s'ils se sentent coincés dans le temps, la revu sera bâclé ou bypassé.

Et vous, avez-vous eu d'autres expériences de revue de code ? Des histoires sur le sujet ? Maxime Savard