Comment faire une code review ?

Vous venez de finir de développer une fonctionnalité mais vous aimeriez faire relire votre code puisque j’ai réussi à vous convaincre suite à mon article sur la code review. Seulement, vous ne savez pas comment faire ?

Une revue de code, ça se prépare

Evident ? Pas tant que ça. Trop souvent, un développeur vient voir son collègue pour lui demander gentiment d’aller regarder sa pull request (cela implique l’utilisation de Git) qu’il vient de faire. Mais, est-il au courant de ce que votre code est censé faire ? Des contraintes que vous avez eu ? Lui avez-vous demandé uniquement parce que c’est votre supérieur hiérarchique ou parce que c’est un développeur plus expérimenté ? En bref, plein de raisons qui pourraient mettre en péril votre revue de code.

Simple ou double ?

Tout d’abord, il vous faut choisir votre “type” de code review. Elle peut être faite par une seule personne mais aussi par un groupe. Ce choix implique différents points :

Novice ou expérimenté ?

Quoiqu’il arrive, c’est à vous et seulement à vous de faire ce choix puisqu’il va dépendre de chaque équipe mais aussi des différents relecteurs.

Les 2 mon capitaine ! Le fait de choisir les deux types de professionnels vous permet de combler toutes les faces d’une relecture. De base, j’aime penser que l’on a tous à apprendre de quelqu’un (même Elon Musk). Chaque individu a sa propre expérience, sa vision de voir les choses et sa manière de comprendre. Faire relire son code par un novice qui ne trouve rien à redire, ce serait presque un bon point “automatique” pour la compréhension du code ! A l’inverse, il ne faut pas en conclure qu’il n’y a pas de bugs et qu’il n’y a rien à revoir.

Une fois que vous avez choisi ces différents critères, comment se passe une code review et que doit-on regarder ?

Définissez vos standards

Outre les standards du langage comme PHPCS pour PHP, l’architecture que vous avez mis en place respecte forcément un standard que vous avez conçu au fil du temps.

Prenons l’exemple d’une entité. Dans votre application, vous avez décidé de faire une class par entité qui s’occupe spécialement de la préparer pour renvoyer les bonnes informations au format JSON. De fait, si le nouveau code a une nouvel entité, la personne a-t-elle bien pensé à faire ce qu’il faut pour que son entité soit retourné comme il faut au format JSON ? Peut-être avez-vous mis en place des tests unitaires, sont-ils réalisés ? Tout une suite de question qui vont plus loin qu’un simple coding standard.

SOLID comme un roc

Encore ce principe SOLID. Vous l’aurez compris, j’y attache énormément d’importance mais je ne suis pas le seul. Je pense que c’est un principe fondamental. Relire du code objet sans s’en préoccuper et vous irez tout droit dans le mur.

Je fais que du code procédural, ça ne me sert pas.

Détrompez-vous, on peut tout à fait contourner le principe SOLID et l’appliquer sur du code procédural. Son acronyme changerait forcément car certains principes sont liés à l’objet en tant que tel. Mais, c’est le genre d’article qui pourrait venir dans les prochaines semaines : réfléchir à l’application du principe SOLID sur du code procédural.

De manière générale, il faut relire tout ce qui vous semble bon à revoir. Les premiers points cités au dessus sont très importants mais, pour ne pas tous les citer, voici quelques grands sujets dont il ne faut pas passer à côté :

• La sécurité
• L’existence d’une variable ou d’un index (dépend du langage également). Mais combien de fois vous retrouvez les fameux undefined index
• La complexité algorithmique (qui va donc de pair avec la compréhension du code souvent)

Surtout, prenez le temps ! Quoiqu’il arrive, on ne peut pas faire des choses de qualité dans un temps très restrictif (petite vidéo sur Facebook qui illustre de très nombreuses situations liées au temps).

Enfin, il peut vous arriver de ne pas réussir à tomber d’accord, surtout lors d’une relecture à plusieurs. Je vous conseille alors d’établir un système de point pour catégoriser un degré d’importance à ce que vous remarquez.

Enfin, il peut vous arriver de ne pas réussir à tomber d’accord, surtout lors d’une relecture à plusieurs. Je vous conseille alors d’établir un système de point pour catégoriser un degré d’importance à ce que vous remarquez.

Par exemple :

A l’inverse, on n’est pas là non plus pour tomber et s’éterniser dans du social. On est là pour produire et certifier que ce qui est en train d’être fait est de qualité et que l’on est pas passé au travers de quelque chose. Cela n’empêche en rien d’être aimable avec le développeur à qui vous aurez affaire mais d’être intransigeant avec le code.De plus, outre les différentes notes et le fait de se mettre d’accord sur ce qu’il faut relever comme erreurs, faire une relecture de code c’est aussi faire face aux égos de chacun. La relecture de code comporte donc aussi une dimension humaine et psychologique. A travers vos critiques, vous allez affecter votre équipe. L’idée n’est pas de les casser mais de les accompagner. Le savoir-transmettre sera tout aussi important.

Terminons par la correction

Une fois que vous avez effectué votre code review, il est l’heure de corriger les différentes remarques. Évident encore une fois ? Pas toujours… Faites le tout de suite sans plus attendre et ne procrastinez pas, sinon gare à la dette technique qui vous pendra au nez.

Mais qui doit corriger ? L’auteur !

Ne corrigez jamais à la place de l’auteur sinon, comment apprendra-t-il de ses erreurs ? Même si c’est un sentiment fort que l’on retrouve chez les développeurs chevronnés qui se disent : “Au moins, j’irai plus vite et ce sera propre”. Vous acceptez de perdre à nouveau du temps sur la prochaine relecture. Si votre poulain ne peut pas se corriger, comment apprendra-t-il ? C’est en forgeant que l’on devient forgeron et non en faisant du mimétisme (vous savez, le fameux copié / collé ).

Enfin, si vous avez encore des doutes sur la façon de faire ou de comment l’aborder, n’hésitez pas à me contacter et rencontrons-nous !