Organiser un coding dojo : choisir un kata et le dérouler en TDD
Un coding dojo rate le plus souvent pour une raison simple : le groupe traite la séance comme une mission avec une deadline plus courte, alors que l'objectif n'est pas de finir l'exercice, c'est d'observer et de discuter la façon dont on le résout. Le format et le kata choisi déterminent si cette distinction survit à la première demi-heure.
Deux formats, deux dynamiques différentes
| Format | Déroulé | Ce qu'il favorise |
|---|---|---|
| Randori | Un binôme au clavier devant le groupe, rotation toutes les 5-7 minutes | La discussion collective, chaque rotation reprend là où la précédente s'est arrêtée |
| Practice-in-pairs | Tous les participants en binômes simultanés sur le même kata | Plus de code écrit par personne, mais moins de discussion partagée |
Le Randori convient mieux à un groupe qui découvre la pratique : la rotation fréquente empêche un binôme de s'enfermer dans une seule direction, et le reste du groupe observe activement plutôt que de coder en parallèle sans jamais voir les autres approches. Le practice-in-pairs convient mieux à un groupe déjà habitué, qui veut comparer plusieurs solutions indépendantes à la fin de la séance.
Choisir un kata : les critères qui comptent
Un bon kata pour une séance de 60 à 90 minutes doit tenir trois contraintes à la fois : être assez petit pour être terminé dans le temps imparti, assez riche pour révéler une vraie tension de conception, et ne pas reposer sur une astuce qu'il suffit de trouver pour que tout le reste devienne trivial. Ce dernier point élimine beaucoup de katas d'apparence populaire : un problème qui se résout par un « aha » ponctuel transforme la séance en chasse à l'astuce, pas en pratique du TDD.
| Kata | Ce qu'il force à travailler | Pourquoi il fonctionne bien en dojo |
|---|---|---|
| String Calculator | Escalade progressive des règles (séparateurs multiples, exceptions, délimiteurs personnalisés) | Chaque règle ajoutée force un nouveau cycle rouge-vert-refactor sans jamais tout réécrire |
| Bowling Game | Calcul incrémental d'un score avec des règles qui se chevauchent (spare, strike) | Révèle la tentation de sur-complexifier trop tôt, avant que les cas simples ne suffisent |
| Roman Numerals | Traduire une règle de conversion sans if/else en cascade | Bon terrain pour pratiquer les techniques d'évitement des conditions imbriquées |
| Mars Rover | Modéliser un état (position, direction) qui évolue par commandes | Bon support pour discuter sealed classes ou modélisation d'état en général |
FizzBuzz, malgré sa popularité, ne tient pas la distance : la solution complète tient en quelques lignes dès le premier cycle, ce qui ne laisse rien à explorer une fois le premier test vert.
Dérouler le Bowling Game kata en TDD, étape par étape
Le Bowling Game illustre bien l'escalade progressive attendue d'un dojo. La séquence de tests classique, dans l'ordre où elle est écrite :
- Partie entièrement ratée (tous les lancers à 0) : le score attendu est 0. Premier test, implémentation triviale.
- Partie sans bonus (tous les lancers à 1) : le score attendu est 20. Force une première boucle de calcul, sans encore gérer spare ni strike.
- Un spare (un lancer à 5, un lancer à 5, un lancer à 3, le reste à 0) : le score attendu est 16. La frame du spare vaut 10 plus le lancer suivant (10 + 3 = 13), la frame suivante vaut 3. Ce test force la généralisation du bonus de spare.
- Un strike (un lancer à 10, puis 3 et 4, le reste à 0) : le score attendu est 24. La frame du strike vaut 10 plus les deux lancers suivants (10 + 3 + 4 = 17), la frame suivante vaut 7. Ce test force la généralisation du bonus de strike, structurellement différente de celle du spare (deux lancers suivants, pas un seul).
- Partie parfaite (douze strikes) : le score attendu est 300. Ce dernier test vérifie que la dixième frame, qui a une règle spéciale (deux lancers bonus au lieu d'un), est bien gérée par la généralisation déjà en place.
Chaque étape suit la discipline détaillée dans l'article sur le vrai TDD : test d'abord, rouge vérifié, implémentation minimale, refactor avant de passer au cas suivant. Le bénéfice pédagogique du dojo vient précisément de ce séquencement : sauter directement à l'implémentation générale du calcul de score, sans passer par les cas intermédiaires, prive le groupe de la partie la plus intéressante de la discussion, celle sur pourquoi chaque généralisation est apparue au moment où elle est devenue nécessaire, pas avant.
La contrainte volontaire, un outil sous-utilisé
Ajouter une contrainte artificielle (« pas de boucle for », « pas plus de trois lignes par méthode », « commit toutes les deux minutes ») force le groupe à explorer une direction de conception qu'il n'aurait pas prise spontanément. Ce n'est pas une complication gratuite : c'est la façon la plus fiable de faire ressortir des techniques de conception que la solution la plus naturelle ne révèle jamais, précisément parce qu'elle paraît trop évidente pour être discutée.
Ce qu'un dojo n'est pas
Un dojo n'a pas vocation à produire du code qui part en production, ni à départager la « meilleure » solution entre les binômes. La rétrospective de fin de séance vaut plus que le code produit : comparer deux solutions différentes au même kata, comprendre pourquoi l'une a émergé plus tôt ou plus tard dans la séquence de tests, est l'exercice qui transfère réellement vers le travail réel, bien plus que l'exercice lui-même.