J'ai tenté de présenter le Kata "Jeu de la vie optimisé".
Voilà comment çà c'est passé :
L'idée était de reprendre et de continuer le joli coup de Manu : utiliser des grands entiers au lieu de chaînes de caractères pour représenter les entités qui naissent, survivent ou meurent dans le jeu de la vie. En Ruby, les grands entiers font une sorte de pont entre le niveau d'expression du langage et la représentation interne propre aux microprocesseurs, et ce pont permet des parallélisations intéressantes, notamment grâce aux opérations de masquage. J'avais donc un plan, plusieurs répétitions dans les doigts, et donc de quoi faire une présentation prometteuse (pensez donc : une division par dix du temps de calcul !).
Je n'ai pas tenu les délais, et même si les avais tenu, je crois que la présentation n'aurait pas suscité un grand enthousiasme. Mais j'ai appris deux ou trois choses que je ne savais pas encore à propos de cet exercice.
Tout d'abord, j'ai voulu en faire trop en même temps : articuler une solution à base de mise en table des résultats possibles du calcul de génération, masquage et décalage pour "fenêtrer" la zone de calcul dans le terrain, utiliser par convention un "bord" du terrain pour simplifier la routine centrale (pattern Sentinelle).
Ensuite j'ai présenté une approche typiquement "j'ai un plan (mais vous ne saurez vraiment qu'à la fin que ça peut marcher)", plus communément appelée approche "Bottom-Up" : on part des briques de base pour en construire des plus grandes puis des pans entiers et enfin le programme. C'est intéressant, mais çà donne au Kata un certain suspense qui nuît à sont aspect narratif. Le consensus autour de la démarche TDD n'est pas une simple coïncidence au Dojo : le code présenté doit se dérouler naturellement test après test, et la forme doit émerger de ce déroulement. Ce qui se passe dans le cas contraire, c'est la promesse d'un dénouement final, avec le risque que le gong sonne trop tôt. Mais le public ne vient pas au Dojo pour le suspense.
Enfin, j'ai ressenti avec une vivacité particulière le conflit inhérent à l'exercice d'équilibriste que nous appelons le Kata : vous devez exécuter un design dans un temps imparti. Vous devez faire en sorte que ce design passe les tests qui correspondent à l'énoncé et aussi que ce design soit approuvé par votre auditoire. Si bien qu'il y a grosso modo deux façons (non exclusives) de chuter sur le tatami : l'heure à sonné, ou le public a décroché.
A un moment donné, j'étais aux prises avec
- une initialisation de tableau défectueuse,
- une remarque à prendre en compte sur l'expressivité de mon code
- une remarque à prendre en compte sur un prochain test possible qui ne passerait sûrement pas
- le délai qui, lui, était passé de plusieurs minutes.
Et j'ai pensé "Bien sûr, ILS peuvent m'interrompre à tout bout de champ, et comme ça m'empêcher de finir.", Cette bouffée de parano a produit un déclic, et m'a fait réaliser l'absurde de la situation : réclamer l'arrêt des interruptions pour faire passer mon code. Comme je ne voulais pas non plus réclamer du temps (c'est inutile) j'ai jeté l'éponge, et tout est redevenu normal.
Et voilà ce que j'ai appris :
Le Kata est un exercice difficile de programmation et de communication, durant lequel il est impossible de ne pas éprouver la boucle de rétroaction positive PRESSION / QUALITE : le stress lié à l'enjeu et aux délais vous pousse à la précipitation; la précipitation engendre des défauts, un exposé moins clair; il faut corriger et réexpliquer, ce qui prend du temps et accentue le stress lié aux délais.. Comme dit Manu, "Tu réexplique une fois, et c'est cuit". Par conséquent les progrès sont à trouver autant du côté programmation (élégance, expressivité, connaissance des patterns de base) que du côté communication (idées, design, expressivité, rigeur, et surtout écoute des autres).
C'est une épreuve sous-tendue par une discipline. Il me semble qu'un Kata réussi doit répondre au critères suivants :
- énoncé satisfait
- code répondant aux 4 règles : passe tous ses tests, exprime l'intention, ne contient pas de redondance, économe en classes/méthodes/lignes
- respect des délais
- adhésion de l'assemblée à l'exécution présentée.
Ce dernier point est particulièrement critique. Le Kata est un exercice collectif. Vous ne pourrez jamais réussir une présentation "malgré" vos auditeurs.
Il me semble que quand on est capable de réussir cet exercice, on est mieux préparé pour répondre à ces défis quotidiens du développement logiciel en équipe :
- trouver une rapidement et concrètement une solution correcte à un problème,
- exposer une idée de design et la rendre faisable pour l'ensemble de l'équipe,
- écouter, comprendre et se faire comprendre.
C'est un exercice fascinant, autant par les illusions qu'il vous fait perdre à propos de vos compétences que par les ressources inconnues qu'il permet de découvrir en vous.
Enfin, même flanqué sur le tatami avec un genou douloureux, c'est toujours aussi génialement amusant.
J'ai comme l'intuition que dans un an ou deux, nous pourrons, à force d'entraînement, réussir cet exercice : coder en une heure une solution correcte, expressive et approuvée, sur un sujet tiré au hasard. Autrement dit, devenir virtuose au point de savoir improviser.
Posted by Christophe at April 7, 2005 09:01 PM