La revue de code - Partie 4
Ou comment resserrer les liens
May 20, 2015
Alors qu’il baigne dans une équipe au niveau technique relativement haut, Dave Lawper se sent seul. Il a passé sa semaine à se casser les dents sur des difficultés, livré à lui-même. Les seules intéractions avec ses semblables se sont fait dans la tension, voire l’animosité. Sa bêtise du vendredi précédent est resté en travers de la gorge de la plupart de ses collègues, et il n’a pas amélioré sa situation en requérant de l’aide à plusieurs reprises. Sa méconnaissance du code front-end a fini de les exaspérer, augmentant d’autant plus la pression pesant sur ses épaules. Seul face à l’adversité, se battant avec des défis techniques hors de son monde d’origine très orienté back-end, les quelques jours ont été très mauvais pour son moral.
Isolé et sous pression. Un bon coktail pour faire craquer n’importe qui. Et tout ça, simplement à cause d’une fichue lib que personne ne connaissait. Dans le fond, ce n’était pas vraiment la faute de Dave Lawper. L’équipe n’a-t-elle pas, après tout, sa part de responsabilité ? Avoir laissé Dave Lawper se débrouiller seul sur un code aussi critique n’est-il pas de l’ordre de la faute commune ?
Tu veux dire que Dave Lawper a écrit du mauvais code à cause de ses collègues ?
Posons-nous un instant la question. La même situation n’aurait-elle pas pu se produire si Deb Lopez avait été à sa place ? Après tout, personne ne connaissait cette lib. Dave Lawper n’est pas un développeur plus mauvais qu’un autre. N’importe qui aurait pu provoquer une catastrophe de cette ampleur, au vu de la situation. Et pourtant, c’est Dave Lawper le vilain petit canard aux yeux du reste de l’équipe. Même si le développement est justement un travail d’équipe. C’est bien là que ça pêche. Rien de ce qui s’est passé cette semaine-là n’aurait dû arriver dans une véritable équipe.
Nous avons vu que la revue de code est un partage de connaissances et de compétence entre les développeurs. Que se passe-t-il donc quand on augmente les intéractions entre deux membres d’équipe ?
Ils se comprennent mieux. Ils s’entraident plus volontiers, Ils connaissent les forces et les faiblesses de l’autre. Bref, l’équipe démontre une bien meilleure cohésion.
C’est bien le manque de cohésion qui a fait défaut à l’équipe de Dave Lawper. Seul et sur un code inconnu, il n’a même pas eu le réflexe d’aller demander de l’aide. A moins qu’il n’ait craint de le faire. Dans tous les cas, il a volontairement préféré rester seul. Or, s’il avait été habitué et bien intégré dans l’équipe, c’est tout naturellement qu’il se serait tourné vers Deb Lopez à partir du moment où il s’est rendu compte des obstacles. Deb Lopez, ou n’importe qui d’autre dans l’équipe ayant des notions sur ce bout de code. Il aurait ainsi pu éventuellement travailler en binôme, réduisant les risques pour au final un coût acceptable. En bonus, il aurait renforcé sa cohésion avec ce binôme, et la revue de code aurait été faite implicitement. Le code aurait été bien mieux vérifié, et l’équipe s’en serait retrouvée plus soudée.
Dans l’éventualité où il n’aurait pas travaillé en binôme, chose réservée à des situations assez critiques ou des domaines tels que l’aviation, il aurait tout de même obtenu de l’aide, des pistes, ou n’importe quelle information intéressante pour l’aider dans sa tâche. Et la revue de code finale aurait achevé le travail de sécuriser le correctif. Dave Lawper ne se serait donc pas retrouvé seul, vendredi soir, à pester contre le mauvais sort en produisant un correctif de mauvaise qualité.
Comme on peut le voir, la revue de code est le premier pas vers la cohésion d’équipe. Si les différents membres se “forcent” à se côtoyer régulièrement, cette relation deviendra au fil du temps de plus en plus naturelle. Elle ouvrira même la porte à une communication plus aisée, et au final une meilleure ambiance au sein de l’équipe. Les échanges seront fréquents, et de qualité, ce qui amènera obligatoirement une meilleure répartition des connaissances et des compétences, réhaussant d’autant plus le niveau global de l’équipe.
Ainsi, plus de code crade dans un coin, plus de choix technique unilatéral, plus d’équipe silencieuse à se regarder en chien de faïence en se demandant ce que bien faire le collègue en face. Les intéractions sont facilités et la productivité améliorée.
En bref, la revue de code est le premier pas vers la cohésion d’équipe.
Rémi Doolaeghe est un développeur freelance Java partisan du manifeste agile et de l'artisanat logiciel. Il a développé son expérience pendant 5 années au service d'éditeurs de logiciels de la métropole lilloise avant de devenir développeur indépendant. L'agilité et la collaboration sont ses moteurs dans un univers où l'expertise technique à elle seule n'est qu'un premier pas vers l'excellence.
Partagez cet article :