Pourquoi ces trois mots apparemment sans lien ? Pour vous parler d'une séance dont le dojo était Valtech et l'objectif était de découvrir par la pratique le langage Ruby. La première partie de la séance fut un...
Kata Randori
Les postes de développement Ruby ont été constitués sur le vif (l'environnement Ruby pour Windows mis en place à l'aide d'un [installeur](http://www.ruby-lang.org/en/downloads/)). Le moins que l'on puisse dire, c'est que les configurations hétérogènes nous ont quelque peu pimenté la tâche : MacBook, PC sous XP et Linux !
Nous avons ensuite choisi le kata (i.e. l'énoncé de l'exercice) à effectuer : "Missing word in dictionnary". Un exemple vaut mieux qu'un long discours ici :
dictionnaire : ["a", "big", "white", "cat"] entrée : "a tiny black cat" sortie : ["tiny", "black"]
Le principe retenu fut de positionner deux rôles par poste : un développeur (à gauche) et un **copilote** (à droite). Il est possible d'ajouter un troisième rôle : l'**observateur** dont la fonction est juste d'observer... sans communiquer.
Le "Time-boxing" requiert un décalage de rôle toutes les cinq minutes. Le copilote devient développeur et le développeur devient copilote sur le poste de gauche ! On passe donc cinq minutes sur chaque poste.
Bien entendu, cette mobilité contraint la méthode de développement :
C'était la première fois pour une majorité d'entre nous : Ruby, coding dojo, pair programming et dans une moindre mesure, TDD (Test Driven Development). Pour moi, cela a changé la façon de voir le TDD car en "solo programming", je n'appliquais pas les baby tests. J'avais toujours tendance à vouloir implémenter l'algorithme que j'avais dans la tête, et pas celui induit par les tests. Le pair force à ne pas brûler les étapes et réduit le gaspillage en implémentant le strict nécessaire aux tests.
Au final, au cours de la rétrospective qui a suivi, on a pu faire le point pour trouver de meilleures façons de travailler. Le point crucial pour terminer une implémentation correcte fut la connaissance des API du langage Ruby qui permet évidemment de raccourcir le code à écrire.
Cette forme de développement abolit de manière assez spectaculaire la propriété du code. Une chose amusante à constater est la diversité des solutions choisies de poste en poste. Cependant, le niveau de test et leur complétude est comparable car tout le monde avance en parallèle sur le sujet, ce qui est troublant et donne un côté magique... On a tellement l'habitude de trouver un code au même stade où on l'a laissé.
Après une discutions a posteriori, nous avons tout de même laissé de côté une phase préliminaire : la spécification des tests. En effet, au lieu que chaque binôme définisse incrémentalement les tests, une liste de tests ou une "spécification" peut être préparée pour savoir où on veut en venir...
Kata Préparé
La rétrospective ayant fait remarqué notre méconnaissance de Ruby, la deuxième session fut un kata préparé effectué par celui qui connaissait le mieux le langage, Etienne Charignon. Ce fut l'occasion de choisir un sujet riche en apprentissage : le comptage du nombre de lignes de code dans un programme Java (hors commentaires et lignes vides).
Pour conclure, je dirais que le coding dojo permet de **pratiquer**, une très bonne façon de comprendre et d'assimiler la méthode et les concepts sous-jacents. Il est une chose d'en parler mais le vivre est encore mieux. On apprend aussi sur soi-même pendant le codage en pair. Ce n'est pas un moment où on est jugé par son pair mais bien une façon d'avancer ensemble et de tirer le meilleur parti des deux "cerveaux"... C'est un challenge à la fois amusant et instructif qui peut permettre de souder une équipe très rapidement.
Liens : les [slides](http://docs.google.com/Presentation?id=dd5nxwg6_0gm3kqjfs) coding dojo.