Comment merger sa Pull Request en 5 secondes ?

Pour merger sa pull request en 5 secondes, il faut …

Pour merger une pull request en 5 secondes, il faut :

1. Ouvrir la pull request
2. Valider et confirmer le merge de la pull request
3. Avoir fait tout ce qui se fait d’habitude à partir de l’ouverture de la pull request !
4. Prendre un café bien mérité

Je vais vous partager comment nous avons, dans une équipe de 5 développeurs, mis en place des pratiques réduisant le temps de context switching pour les revues de code, les conflits de merge ou rebase, rendu tout le monde opérationnel et responsable sur l’ensemble de la base de code et finalement aligné toute l’équipe dans notre façon de développer.

Je reviendrai sur 2 des pratiques XP qui nous ont permis d’en arriver là :

1. Pair / mob programming
2. Mob review

Le pair programming / mob programming

J’ai eu la chance d’être Tech Lead dans une équipe que j’ai complètement recrutée. Donc j’ai choisi dans mon équipe des développeurs ne connaissant que la théorie des pratiques craft mais qui souhaitaient s’engager dans cette voie.

Sur notre projet, nous n’étions au début que 2, nous faisions du pair programming tout le temps.

Puis j’ai intégré un nouveau développeur, pour passer à 3. L’onboarding s’est fait en pair programming avec le nouveau. Nous alternions la pair, l’autre restant de son côté.

Pour rappel, le pair programming consiste pour deux développeurs à travailler en même temps sur une fonctionnalité. Les 2 développeurs utilisent un seul ordinateur / clavier et se répartissent 2 rôles :

• Le navigator décide ce qui doit être implémenté, dirige la construction des tests et du code de production
• Le driver est au clavier et fait l’implémentation en suivant les indications du navigator

Ensuite j’ai intégré un quatrième développeur lors du premier confinement au printemps 2020. Cela a permis de faire deux pairs pour coder. Nous faisions tourner les pairs régulièrement afin d’apprendre à mieux se connaitre et homogénéiser nos pratiques et standards de développement. Ceux-ci étaient par la suite inscrits dans des ADR : Architecture Decision Record.

Finalement, j’ai intégré un cinquième développeur alors que nous étions encore tous à 100% en télétravail. Sa particularité était de ne faire que du front. Mais de la même façon, nous l’avons intégré en faisant du pair programming.

Le covid a presque rendu les moments de développements synchrones plus efficaces, car chacun était bien installé en face de son écran. C’était plus facile de bien voir le code et de rester attentif.

Nous faisions aussi parfois du mob programming, surtout dans les cas suivants :

• Quand nous attaquions une fonctionnalité complètement nouvelle
• Quand nous démarrions une partie technique sur laquelle nous avions beaucoup d’inconnus afin que tout le monde puisse apporter des idées et s’approprie la solution choisie
• Quand j’ai voulu faire évoluer l’architecture vers de la clean architecture puis du CQRS.

Pour rappel, le mob ou ensemble programming est l’équivalent du pair programming mais pour l’ensemble de l’équipe technique. Les différences principales sont les suivantes :

• Le navigator va chercher auprès de l’équipe (hors driver) des idées sur ce qui doit être implémenté afin de garder de la dynamique dans le groupe
• Les personnes qui ne sont ni driver, ni navigator sont là pour proposer des idées, s’assurer que ce qui est implémenté correspond bien à ce qui est souhaité et apprendre ensemble

Mais pour s’assurer que tout le monde ait connaissance de ce qui avait été développé, j’ai mis en place du mob review.

Le mob review

Lorsque nous étions que 2, la revue de code se faisait à 2 au fil de l’eau, même si je préférais dédier un temps après avoir terminé le développement pour revenir sur ce qui vient d’être codé. Cela permettait aussi à nos cerveaux d’être en mode check plus que design.

Lorsque nous sommes passés à 3, à chaque fois que la pair ou le dev solo avait terminé son développement, on se sollicitait pour faire une revue de code tous ensemble (mob review).

Un des développeurs présentait ce qui avait été développé, les petits retours étaient traités en live et les retours plus importants étaient notés par un scribe pour que la pair ou le developpeur fasse les corrections.

Une fois les fixs réalisés, on se remobilisait pour vérifier la correction qui était ensuite immédiatement mergée sur master : l’ouverture de la pull request n’était faite qu’à ce moment là.

Quand nous sommes passés à 4 puis à même à 5, nous avons continué ce mode de revue de code.

Or, le nombre de streams de développement est passé de 1 à 3 voir 4, rendant les interruptions pour faire les revues de code de plus en plus fréquentes, cela pouvant nous interrompre à n’importe quel moment. De plus, certaines sessions de revue de code ont vu leur temps s’allonger, réduisant leur efficacité. Généralement, au bout de 20 minutes, l’attention diminue.

Retrospective tech

J’organisais une fois par itération de 2 semaines, une rétrospective tech pour faire de l’amélioration technique sur la partie technique et dissocier nos sujets tech des sujets organisationnels.

Lors d’une rétrospective tech, nous avons levé le fait que les interruptions pour les revues de code devenaient trop nombreuses et nous perturbaient trop dans le flot des développements. Nous avons proposé puis testé le mode opératoire suivant :

• En début de chaque demi-journée, on se réserve un créneau de 15-20 minutes pour présenter le code réalisé.
• Nous avons nommé un time keeper et un facilitateur pour s’assurer de ne pas traiter lors des revues de code de sujets impactant l’architecture ou des évolutions de nos standards de code. Ces sujets étaient notés pour être traités durant la prochaine retrospective tech bi-hebdomadaire.
• Les fixs des revues de code étaient tout de même réexaminés par l’ensemble de l’équipe lors de la demi-journée suivante

Mais même avec ce nouveau mode opératoire, les revues des fixs prenaient encore trop de temps et n’apportaient que peu de valeur ajoutée.

Nous avons finalement modifié ce qui suit et enfin adopté et conservé ce mode de fonctionnement :

• Si la première revue demandait de revoir pas mal de design dans l’implémentation, on faisait quand même un mob revue des modifications
• Sinon, pour les revues de petits fixs notés durant la première revue une PR était ouverte et un seul relecteur validait et mergeait la pull request.

Les avantages et prérequis de ce mode de revue de code et dans quels cas ça marche

Les avantages

• Puisque tout le monde validait toutes les demi-journées le travail de l’ensemble de l’équipe, nos features branches avaient des durées de vie très courtes (généralement moins d’une 1 journée), on livrait en recette de manière continue, ce qui rassurait les PO sur notre capacité à merger et à livrer des nouvelles fonctionnalités.
• Une émergence et un alignement des standards de code de manière fluide et naturelle : les discussions lors des mob reviews ont permis de définir les standards de l’équipe.
• Tout le monde sait ce qui est développé : que ce soit fonctionnellement ou d’un point de vue code / architecture.
• La polyvalence de tous les développeurs sur l’ensemble de la base de code a permis la suppression du bus factor.
• Une grande facilité pour onboarder de nouvelle personne : elle voit très rapidement tout ce qui est développé sur l’application et ne rate pas une ligne de code mergée sur master.

Les prérequis

• Il faut être dans un contexte dans lequel personne ne vous impose ou interdit vos pratiques de développement. Est-ce que vous demandez à votre dentiste de ne pas mettre de plombage une fois la carie enlevée ?
• Il faut qu’il y ait une sécurité psychologique importante entre les tech de l’équipe pour montrer son code. C’est vrai quand on fait des revues de code mais encore plus quand elle se fait en live. L’egoless programming est indispensable.
• Il faut que tout le monde joue le jeu, sinon, le mob review perd tout son intérêt.

Je pense que ce mode de revue de code a fonctionné pour les raisons suivantes :

• J’ai recruté mon équipe et j’ai fait attention que celle-ci soit curieuse de voir d’autres pratiques.
• Mon client avait complètement confiance en moi et ne s’immisçait pas dans la façon dont je gérais l’équipe de développement
• On se disait les choses et on avait le droit à l’erreur. L’évolution de l’architecture ne s’est pas faite en suivant un long fleuve tranquille, mais ça sera le sujet d’un autre article.

Voici dans quels cas je ne pense pas que ce mode de review soit adapté :

• Le monde de l’open source : équipe distribuée, sur des fuseaux horaires différents, travaillant en mode best effort. C’est de là que viennent les pull request/merge request mais c’est exactement le contraire de ce qu’on vit en tant de développeur.euse !
• Quand les développeur.euse.s ne sont pas à l’aise en groupe et préfèrent travailler chacun dans leur coin
• Quand (presque) personne s’intéresse vraiment à ce que font les autres développeur.euse.s.
• Quand il n’y a pas d’enjeu pour livrer rapidement de nouvelles fonctionnalités (en production). C’est tout l’opposé de git flow.

Conclusion

Cette façon de faire des revues de code a été une expérience très enrichissante car elle m’a permis :

• D’onboarder des nouveaux développeurs très rapidement
• D’apprendre à les connaître plus rapidement et cela même pendant les confinements de 2020-2021
• De faire évoluer ma façon de coder grâce à mon équipe

Je vous encourage à tester au moins une fois cette façon de faire des revues de code. Je suis persuadé que vous découvrirez plein de choses et pas seulement technique.