Et si on arrêtait les revues de code ?
Qu-Quoi ?! On arrêterait de contrôler la qualité ? « Hérétique, au bûcher ! » s’exclameraient certains paladins de la relecture de code. Et si, au lieu de contrôler la qualité en fin de chaîne, on co-créait cette qualité tout au long de la conception ?
Oui, je fais allusion au pair programming. Mais avant d’en parler, plongeons-nous dans une histoire. Une histoire que j’ai déjà vécu et que vous avez probablement aussi vécu. Je dirais même que beaucoup ont vécu, d’un côté de la revue ou de l’autre.
Perceval est un des développeurs de l’équipe. Aujourd’hui, il commence une nouvelle tâche. Perceval veut bien faire. Il prend le temps de concevoir cette nouvelle fonctionnalité et de penser son code. Après 4-5 jours, il termine et ouvre une Merge Request. Il passe ensuite à autre chose, une correction de bug.
Le lendemain, Arthur commence la revue de code sur GitLab. Aïe. Ce n’est pas du tout ce à quoi il pensait. Il avait une tout autre vision du design de code. Et il le fait savoir à travers de multiples commentaires écrits. Refaire ci, refaire ça, structurer de cette manière-là, utiliser ces composants, mettre ça ici, etc. Tout un chantier.
Deux heures après, Perceval lit les commentaires. Il met en pause sa recherche d’un correctif et retourne sur la branche de sa première tâche. Il retravaille ses modifications afin de prendre en compte les retours d’Arthur. Ce travail occupera une grande partie de l’après-midi de Perceval. Commit, push, merge request assignée à Arthur. Retour sur le correctif.
En fin de journée, Arthur prend le temps de regarder les changements effectués. Il repense à ce qu’il avait dit à Perceval, et globalement, ce qu’il voit lui plaît bien. Juste quelques petits retours sur des nommages à améliorer et une fonction qui pourrait être créée afin d’éviter la duplication.
Des changements rapides, que Perceval effectuera le lendemain matin. Il y a cependant quelques conflits à résoudre, la branche a pris du retard. S’en suivra une validation de la part d’Arthur une heure après. Tout est validé, la story est terminée et le déjeuner mérité.
Cette histoire vous est-elle familière ? À quel point la vivez-vous ? Vous en êtes-vous déjà rendu compte ? La review est-elle douloureuse pour vous ou votre équipe ? Prenez le temps de vous poser des questions.
Ce que l’on peut observer
Une grande partie du travail est refait. Perceval ayant créé quelque chose qui ne convient pas, du code est jeté. C’est du temps en partie perdu. De plus, la durée de la tâche s’allonge : qui dit suppression dit ré-écriture. Perceval a dû reprendre son travail avec une autre manière de faire. Les chances d’avoir des conflits à résoudre pour merge augmentent, leurs complexités aussi.
Perceval a passé beaucoup de temps tout seul et n’a eu le premier feedback que très tardivement - une fois qu’il pensait avoir terminé, ce qui augmente le coût de re-travail. Arthur a également mis du temps à faire la revue car il y avait beaucoup de code à lire.
Les discussions sont à l’écrit, et en décalées. La revue est ouverte, plus tard des commentaires sont ajoutés, plus tard des retours sont effectués, et ainsi de suite. Le temps d’attente peut être long. La tâche met plus de temps à être terminée.
À chaque aller-retour, il y a un changement de contexte. La personne (auteur ou lecteur) doit arrêter ce qu’elle était en train de faire, doit se plonger dans la revue, puis se remettre sur son ancienne tâche avec la nécessité de se re-plonger dans ce qu’elle faisait. Ce temps n’est pas négligeable.
Et que ressent Perceval ? Quand il apprend qu’il doit tout refaire. Quand il lit les commentaires d’Arthur, sujet à interprétation, pouvant être pris personnellement.
Ce que l’on peut faire
On communique davantage. On donne du feedback tôt et régulièrement. On collabore. Perceval et Arthur peuvent échanger dès le début de la tâche, pendant, et même à la fin lors de la revue. Ils peuvent la faire ensemble sur le même poste. Et soyons fous, ils peuvent se mettre au pair programming. Ça y est, on y vient.
Ce matin, Perceval et Arthur s’assoient côte à côte afin de développer une nouvelle fonctionnalité ensemble. À tour de rôle, ils écrivent du code et échangent tout le long. Ils challengent le code et la qualité. Arthur et Perceval apprennent l’un de l’autre, se transmettent des connaissances, des bonnes pratiques.
À la fin de la journée, la fonctionnalité est terminée. Le design du code et la qualité sont encore meilleurs que ce qu’ils pensaient faire chacun dans leur tête avant de commencer. Ils rapatrient la fonctionnalité sur la branche principale. Fin.
Qu’en pensez-vous ? Remémorez-vous la première histoire.
En travaillant de paire, le feedback est immédiat et continu. Arthur accompagne en temps réel Perceval. Il n’y a plus d’aller-retour ou d’échanges à l’écrit, ni d’attente, ni de changement de contexte. Il n’y a même plus besoin de faire de code review, chaque retour a été pris en compte sur le moment et le résultat est de meilleure qualité. Avec le pair programming, la revue de code est poussée à son extrême : le binôme en fait tout le long, à chaque instant.
Les échanges sont plus humains et plus riches. Chacun apprend, partage. Chacun challenge et améliore le code écrit. Chacun comprend le code et la fonctionnalité - la propriété est collective. Les bénéfices du pair programming sont multiples. Alors pourquoi attendre ? Une heure, une journée, une fonctionnalité de bout-en-bout, … Lancez-vous. À votre rythme, mais lancez-vous.
Testez, observez ce qui change, prenez du feedback. Apprenez à faire du pair programming, acceptez au début de ne pas savoir faire, améliorez-vous. Et appréciez :)
Post-scriptum du prêtre : toute ressemblance avec des personnes existantes ou ayant existé dans la légende arthurienne ne saurait être que fortuite. Ou pas. Je suis en manque de film Kaamelott.