Swiftly

La review du code, des idées pour s’améliorer!

La revue de code constitue l’un des piliers pour assurer la qualité du produit développé. Ce processus est vraiment délicat et peut engendrer même des conflits énormes entre développeurs qui dépassent parfois le cadre professionnel. On peut juger le niveau technique d’un développeur à travers la review de son code mais il faut bien préparer le terrain pour faire une évaluation « cartésienne ». Dans cet article, j’essayerai de vous présenter ma vision de la review de code à travers des exemples que j’ai tiré de mon expérience professionnelle personnelle.

C’est quoi la review du code

La revue du code est un processus de qualité logicielle dans lequel le code écrit par un ou plusieurs développeurs peut être analysé « manuellement » par le reste de l’équipe. Lors de la review, les développeurs essayeront de s’assurer que le code réalise l’objectif du ticket créé et aussi respecte les règles de codage établis au sein de l’équipe. La review d’une nouvelle fonctionnalité assez consistante prendra la plupart du cas plus de temps de vérification que la correction d’un bug simple. La review du code dépendra toujours de la culture et la rigueur de l’équipe. J’ai travaillé avec des développeurs qui font la review par commit (une maitrise de Git est nécessaire dans ce genre d’équipe) et d’autres qui analysent le code verticalement rapidement sans entrer dans les détails du ticket. Pour moi, la review du code est sacrée! (c’est pas le job du lead dev ou tech lead seulement). Non pas pour embêter les gens mais surtout pour avoir une visibilité sur tout le code qui existe et de comprendre ce qu’on voudra livrer pour nos clients. Imaginons que le développeur qui a créé la fonctionnalité n’est pas là avec nous. Il n’y a pas de soucis, les gens qui ont fait la review ou du pair programming sont ici pour prendre un sujet relié à son développement.

Comment je review le code

Je pars du principe que l’équipe a bien établi un code styling clair. Imaginons que je dois faire la review pour un nouveau collègue sénior, confirmé ou junior. Mon approche est toujours de faire du pair programming avec lui, l’appeler et discuter directement à vif voix me permettent de comprendre mieux son code et s’assurer vraiment qu’on a développé tous les cas d’utilisations possibles et qu’on a respecté les critères d’acceptation définis dans le ticket JIRA par exemple. Si on parle d’échange directe, l’expérience m’a appris que c’est toujours une question de modestie et comment la personne se voit lui même. Il est plus facile de faire du pair programming avec quelqu’un d’humble intelligent qui ne se voit pas monsieur programmation ou Turing du développement. En effet, faire de la review avec ces développeurs, te permettent de monter en compétence, d’aimer leur façon de penser et de s’inspirer d’eux. Malheureusement, ils ne sont pas beaucoup. Ils sont des perles rares!

Je décompose généralement ma review en deux grandes parties:

Une première review verticale du code ou j’essaye de regarder si le code respecte le code styling. Néanmoins, on utilise l’outil Swift Lint au quotidien.En effet, ça nous aide énormément pour avoir du code qui respecte notre code styling. Aussi, une solution comme SonarQube permet de gagner du temps et faire de la review statique avant de lancer la pull ou merge request.

La deuxième étape est de prendre en détail le ticket JIRA (On commence le sérieux). J’essaye de lire très attentivement le besoin métier (j’ai déjà une idée sur tout les tickets qui sont dans le sprint alors je découvre pas mais c’est juste pour s’assurer qu’entre temps rien n’a changé! On sait jamais :)). Je vérifie surtout que la solution proposée pour gérer le cas nominale colle bien avec l’architecture et comment surtout je ferai si je codais moi même cette feature!

C’est ici que les choses peuvent déraper malheureusement. On est d’accord que l’architecture assure une bonne partie de la qualité du code et permet aux développeurs de ne pas diverger et de créer une sorte de pattern de comment on pense lorsqu’on code mais ce n’est pas suffisant. Il faut créer ce que je l’appelle un modèle de pensée dans l’équipe tout en gardant l’imagination et la créativité. Ce pattern ou façon ergonomique de penser se crée avec le temps dans l’équipe et tout le monde sentira qu’il y a une ADN ou une marque de pensée algorithmique et technique qui s’installe au fil du temps. C’est pour cela, je répète toujours qu’un bon développeur généralement se crée dans l’équipe non pas tout seul à moins qu’il est sur-doué ou très expérimenté!. Pour anticiper, avec les nouveaux développeurs, on fait énormément du pair programing à tour de rôle. Ceci permet de souder le relationnel humain et aussi de s’aligner tous et de créer cette ADN ou timbre de pensée. En effet, La deuxième partie peut me prendre des jours (pas la totalité mais deux heures au max par journée) et des allers retours entre moi, le développeur, le métier (PO et équipe UX) et les testeurs aussi. Dans l’idéale, l’approche BDD pourra nous gagner beaucoup de temps mais je fais avec et je m’adapte au contexte du travail :).

Un ticket bien écrit doit présenter dans un langage techno-naturel par exemple (GHERKIN) les scénarios simples, complexes et aussi les erreurs possibles qui peuvent écouler. Il faut pas penser seulement au cas idéal au moment d’écrire le ticket, cela impactera la review ensuite. Jusqu’à maintenant, malgré les efforts fournis dans l’équipe, on arrive pas à cerner dés l’écriture du ticket tout les cas qu’on découvre au moment du développement et aussi lors de la review. Pour moi, cela est normal vu que l’ingénierie informatique est un travail empirique scientifique assez complexe dans un langage machine avec beaucoup de dépendances et de side effets non connus tous à l’avance.

Dans certaines organisations, on ajoute la review UX avec l’équipe design pour s’assurer qu’on est au pixel près. Cela nous conduit à ajouter peut être le snapshot testing au niveau de notre CI/CD. Afin de s’assurer avant même de faire la review avec l’équipe UX que notre code respecte le rendu design attendu.

Avec le temps, on a senti que la review s’est amélioré et que la plupart des développeurs de l’équipe ont bien compris l’utilité du code review et s’épanouit à le faire. Je pense que la raison principale que chacun de nous a contrôlé son égo et a compris les avantages de s’intéresser à ce sujet qui apporte beaucoup au produit. La review permet à un développeur junior de passer au niveau supérieur s’il est fait avec des gens expérimentés et humbles.

Conclusion

Le sujet de la review du code est pour moi un tabou dans plusieurs organisations. c’est rare de trouver des boites de tech qui le font bien avec de l’humanisme. A mon avis, même les gens qui prétendent être des crafters ont contribué à rendre ce processus une source pour faire plaisir à leur arrogance non contrôlée (Il y a toujours des êtres humains qui aiment juger et se montrer mieux que les autres). Je prétends pas que le processus de review que j’applique est le meilleur. C’est mon approche, il y a surement d’autres manières plus meilleurs de faire que je suis toujours prenant à découvrir et appliquer.

Leave a Comment

Résoudre : *
28 × 1 =


fr_FRFrench