Coding dojo

Qu’est-ce ?

« Littéralement en japonais, dō signifie la voie (c’est le même caractère que le tao chinois), le dōjō est le lieu où l’on étudie/cherche la voie. » Wikipedia.

« Kata est un terme japonais désignant une forme dans les arts martiaux japonais.
Il s’agit de mouvements codifiés à partir de l’expérience de combattants dont les noms ont été perdus. Les katas sont par la suite devenus des outils de transmission de techniques, mais aussi de principes, de combat. » Wikipedia.

Qu’est-ce qu’un coding dojo ? C’est une session, généralement assez courte (2h – 4h), où collectivement on essaie de résoudre un exercice de programmation, souvent appelé kata. L’objectif n’est pas tant de réussir le défi mais d’apprendre, se perfectionner ou expérimenter sur la manière d’y parvenir en profitant des différents points de vue des participants.
En pratique on utilise des techniques de « l’extreme programming » : TDD, programmation en binôme (« pair programming ») ou collective (« mob programming »), remaniement de code (« refactoring ») …

L’emprunt des termes Dojo et Kata, issus des arts martiaux, reflète bien l’approche qui consiste à accéder à la compréhension par la pratique et la répétition et non par des cours explicatifs classiques.

Les conditions pour participer sont simples : envie d’apprendre et de s’améliorer ainsi que de partager son savoir, son expérience. Ce n’est pas une compétition ni une démonstration de compétences, tous les niveaux sont acceptés.

On s’aperçoit assez souvent qu’il s’agit aussi de sortir de sa zone de confort : on ne se contente pas de réaliser l’exercice comme on a l’habitude de développer – ce qui est facile car la plupart sont assez simples pour être réalisés en moins d’une heure ou deux – mais d’appliquer au maximum les bonnes pratiques (clean code, tests, vraie conception objet, principes SOLID, KISS …) et éventuellement une approche nouvelle. Ce qui, dans un cadre professionnel, n’est malheureusement pas toujours, rarement même, fait ou possible (mauvaise qualité du code existant, compromis qualité / investissement, délai). Ici on peut se permettre d’expérimenter et de prendre le temps de discuter de plusieurs solutions, de les évaluer et de les tester.

Et s’il faut un organisateur qui propose un sujet, ce qui demande un peu de préparation et un peu d’expérience pour ajuster l’exercice aux participants. celui-ci participera généralement à la session comme les autres. Tout le monde pratique, pas d’exception !

Cela s’inscrit dans un mouvement, auquel j’adhère, le « software craftsmanship » qui, je pense, se traduit assez bien par l’artisanat du logiciel.
Ainsi, écrire du code n’est pas une étape réservée aux premières années d’expérience. Au contraire, c’est une activité plus proche de l’artisanat que d’une simple technique que l’on apprend pour ensuite passer à autre chose (qui a dit chef ;-)).
L’artisanat fait penser à l’évolution de l’apprenti au maître artisan et, de même pour les arts martiaux avec la ceinture blanche jusqu’aux dans du maître …
Il évoque la maîtrise du geste, la qualité.

Quels profils peuvent bénéficier de ces pratiques ?

Le débutant : à l’évidence c’est le profil que semble cibler cette approche. Mais le débutant n’est pas toujours celui que l’on croit ; ainsi j’ai déjà croisé des développeurs avec plus de 20 ans d’expérience qui ne connaissaient pas la pratique du TDD. Et on est tous débutant quand survient un changement de paradigme ou de technique …
Le développeur expérimenté : certains des Katas les plus simples lui paraîtront trop faciles. Il est alors assez aisé de les complexifier en rajoutant des contraintes, une évolution des spécifications ou carrément en refaisant l’exercice avec une nouvelle approche (programmation fonctionnelle ou réactive par exemple) et / ou dans un nouveau langage.
Le développeur très expérimenté (expert, architecte logiciel, leader technique …) : au minimum, faire l’exercice fera office de révision et si vraiment il n’y voit aucun intérêt alors son rôle sera de guider les autres (en binôme ou lors de démonstration de mise en œuvre d’une solution). La transmission d’un savoir impose plus qu’un savoir faire : il faut aussi comprendre pourquoi et comment on le fait.
L’encadrement (chef de projet, …) ou les intervenants fonctionnels (expert, responsable produit …) avec toutefois un minimum de bagage technique : participer à l’occasion à quelques séances peut permettre à ceux qui sont éloignés de la technique de comprendre les bonnes pratiques et que l’écriture d’un logiciel ne se résume pas à seulement faire du code qui fonctionne, qu’un développeur fait un meilleur travail en échangeant avec ces pairs.

Organiser un coding dojo dans le cadre du travail demande l’aval de l’encadrement car le temps alloué est pris sur celui du projet mais n’est pas directement productif. Quoique, j’ai déjà participé à une session où l’exercice basé sur du code réel a abouti à une amélioration effective du code du projet. Certes, cela reste plus coûteux que si l’amélioration avait été faite par une personne ou deux (en pair programming) mais un projet peut bénéficier de cette pratique à d’autres niveaux : cohésion de l’équipe, partage d’une approche commune du codage et de la conception, amélioration continue des pratiques …
Pour limiter l’impact sur un projet, on peut envisager une base d’une session de 2 heures toutes les 2 semaines ou de 1 heure par semaine, soit 12 minutes par jour, soit le temps d’une petite pause !
Toutefois si l’entreprise ne souhaite pas prendre en charge ce temps consacré à « s’amuser à programmer », il faudra caler les session dans la pause de midi ou le soir après les heures normales de travail. Mais toutes les personnes ne pourront peut-être pas venir, et dans le cas d’une équipe projet, c’est un peu de cohésion qui s’en va.