Talks

Dans la plupart des équipes de développement les suggestions de code sont faites via des Pull (ou Merges) Request. Elles sont le lieu de discussions asynchrones pouvant prendre des heures voire des jours à se terminer. Des validations sont en plus nécessaires pour les merger ralentissant le rythme des releases de nouvelles fonctionnalités.
Ces échanges écrits peuvent également amener des incompréhensions et une communication violente qui peuvent dégrader la cohésion dans une équipe.
Pendant 2 ans, dans mon équipe, nous avons fait du mob code review avant de merger nos PR. Au lieu de les ouvrir et de faire des code reviews chacun de notre côté, nous nous retrouvions plusieurs fois par jour pour présenter et améliorer le code écrit. C’est comme cela que nous mergions nos PR en 10 secondes​.
Après vous avoir présenté ce concept, je vous expliquerai comment nous avons fait évoluer nos pratiques au fur et à mesure que l’équipe grandissait. Parmi elles, nous souhaitions aligner l’architecture et les standards de code, tout en ayant au sein de l’équipe, une bonne compréhension de l’application d’un point de vue fonctionnel ou technique.
Je détaillerai les difficultés que nous avons rencontrées et les ajustements que nous avons mis en place, les avantages et les inconvénients que j’y vois, ainsi que les conditions nécessaires pour faire du mob review.