Le demi-cercle (épisode 4 -- Driver / Navigators)

Tu es en retard, mais ça vient seulement de commencer. Tu t’installes le plus discrètement possible. Peine perdue, car la personne qui se tient debout près du projecteur t’interpelle, te demande ton prénom et t’explique le but de l’exercice de ce soir.

« On fait un mob, en TDD, sur le kata Bowling Score. Lui — il désigne la personne qui est assise devant le laptop — c’est le Driver. Le Driver écrit le code, mais il ne pense pas. Vous êtes les Navigateurs. Vous dites au Driver ce qu’il doit coder. On change de Driver toutes les cinq minutes. »

- Ok ! Merci ! Pardon pour le retard.

Vous êtes huit en tout, assis en demi-cercle face à l'écran fixé au mur. Deux personnes ont leur laptop sur les genoux. Il te semble qu’ils se connaissent tous. Plutôt jeunes dans l’ensemble, sauf un type qui a bien l’air d’avoir passé la cinquantaine. Audrey avait dit qu’elle viendrait, mais elle a dû être retenue par le boulot. Tu souris. Tu es encore un peu anxieux d’être parti à six heures pile avec ce qui te reste à faire. Une chance que cette réunion se tienne à deux pas des locaux.

- C’est parti ! - Qu’est-ce qu’on fait ?

Le driver se tient devant le clavier et regarde les autres avec un air narquois. Quelqu’un se lance:

- Ecris un test. - Quel test ? - N’importe quoi. Teste que deux plus deux font quatre. On veut voir tourner un test. - Fais-le échouer d’abord. Dis que deux plus trois font quatre.

Le driver s’exécute. Expected 4, but got 5. En bas de l’écran, dans la section consacrée aux messages de statut, une barre rouge s’affiche.

- Maintenant fais-le passer.

Il fait passer le test. La barre est verte. - Et maintenant ?

Une cloche sonne sur le portable du facilitateur. Tout le monde se décale d’une place vers la gauche, y compris toi. Tu es à trois places du poste de driver, un peu inquiet, mais tu te dis que tu as le temps de rentrer dans le jeu.

La personne qui vient de s’installer au clavier se frotte les mains et dit :

- Alors, je pense qu’on pourrait commencer par le cas…

Le facilitateur l’interrompt en mimant le son d’un buzzer de jeux télévisé.

- Tu ne penses pas ! C’est aux navigateurs de réfléchir.

Ton voisin de gauche dit posément :

Commençons par le cas trivial où le joueur ne fait que des gouttières. Dans ce cas le score est de zéro.

Pendant que le driver aligne une vingtaine de zéros dans une liste et peine à trouver le caractère crochet-ouvrant sur le clavier, tu essaies de retrouver dans ta mémoire les règles du Bowling, jeu auquel tu as joué trois fois dans ta vie, il y a plus de dix ans.

L'alarme sonne. Tout le monde change de siège à nouveau.

Le nouveau driver finit d’écrire le test et le fait passer.

- Ensuite ?

Tu te lances, et tu suggères : - Est-ce qu'on ne testerait pas ce qui doit se passer si l'un des lancers est négatif ?

Quelqu’un à l’autre bout du demi-cercle répond : - Ça pourrait arriver, mais est-ce le cas qu’on veut traiter en priorité ?

Quelqu’un d’autre ajoute : - Je vois pas comment la machine qui ramasse les quilles pourrait communiquer un nombre de quilles plus petit que zéro...

Tu rétorques : - Si elle est défaillante ?

La discussion s’enchaîne sur les limites de la programmation défensive.

Le facilitateur lève la main : - Hey !

Tout le monde s’arrête.

- Le driver a quelque chose à vous dire !

Le driver sourit et dis : - Je m’ennuie.

Quelqu’un à ta gauche suggère :

- Aligne vingt lancers sans strike ni spare. Par exemple deux et six, dix fois de suite. Le score sera de quatre-vingts.

Le driver commence à écrire ce test. Sonnerie de cloche. Il cède sa place.

Celui qui lui succède fait passer le test. Tu reconnais le pattern qu’il est en train de mettre en place dans le code. Tu fais des suggestions qui sont bien reçues. Tout le monde semble être parfaitement en accord avec le principe d'écrire le test avant le code qui fera passer ce test, aussi tu te gardes de proposer une autre approche. Curiosité.

Il fait vraiment moins sombre dans cette pièce, que dans celle que tu as laissé derrière ton écran de veille en partant. On dirait que tous les obstacles sont levés d’avance, manifestes, exposés en pleine lumière. Il faut dire que la pièce est toute petite, minuscule même, puisque le problème est particulièrement simple, et qu'on est huit dans cette pièce. Six, si on exclut le facilitateur, et le driver, qui ne pense pas.

Quelqu’un dit : - Est-ce que tu peux écrire Gutter avec deux T ? - Ok. - C’est pareil. - On a pas décidé, mais on code en Anglais ? - On code en Java ! - Tu m’as comprise. - Ok pour l’Anglais. - Bon alors de l’Anglais correct.

C’est à ton tour d’être le driver. Tu n’as aucune idée de ce qu’il faut faire ensuite. Mais ce n’est pas grave. Tu as déjà fort à faire avec ce clavier et cet environnement, qui sont tellement différents de ce que tu utilises au travail.

Quelqu’un propose de traiter le cas du spare. Tu suis les consignes du groupe. Tu ne vois pas exactement où va ce kata, mais tu te débrouilles plutôt bien. Dès que tu cherches un raccourci dans l'EDI, quelqu’un te l’indique. C’est cool. A plusieurs reprises, les demandes des participants se télescopent au point que tu ne comprends plus rien de que veut le groupe, et le facilitateur intervient.

On traite le cas des strikes. Le design que choisit le groupe est surprenant. Tu n’aurais pas codé le kata de cette façon a priori, mais tu trouves que l’approche est assez cohérente. Et puis la dernière fois que tu as écrit une fonction récursive c’était il y a plusieurs années.

Ce qui surprend beaucoup dans cette pièce, ce n’est pas tant la clarté, maintenant éclatante, que l’absence totale d’objets hétéroclites sur le sol et autour des piliers. Chaque chose est à sa place. Cela donne une impression de calme, comme une vibration positive. Tu pressens des nouveautés possibles, mais pas de mauvaises surprises. On voit venir les obstacles de loin. Le plus fascinant, c’est qu’il semble que la pièce, maintenant beaucoup plus grande, dispose d’une architecture parfaitement mobile. Tout à l’heure elle formait un corridor un peu étroit. Quelqu’un dans le groupe a fait remarquer un pattern, que tout le monde devinait sans trouver la bonne façon de le formuler.

« Ce jeu de Bowling, c’est comme un automate à états, avec des états un peu compliqués, mais seulement deux transitions possibles. »

Et à ce moment, la pièce a changé de forme, elle est devenue carrée, avec au milieu, trois piliers et une table triangulaire.

A chaque fois que le groupe s’englue dans une discussion sur ce qu’il faudrait faire ensuite, le facilitateur intervient et suggère d’essayer de faire fonctionner l'une ou l'autre des hypothèses dans un temps limité, plutôt que de continuer à discuter.

Le code est tellement bien testé qu’il paraît impossible d’y introduire une erreur sans que celle-ci ne se manifeste immédiatement. Tu cherches la faille. A deux reprises, tu fais écrire un test qui devrait échouer et montrer qu’il y a un bug, mais le test passe. On en vient aux cas de la fin de partie. Il y a une discussion pour savoir quel score maximum on peut faire au Bowling. L’un des participants ouvre son laptop et fait une recherche.

Quelqu'un dit : « C’est compliqué. Jusque-là, on n’avait pas besoin de compter les frames. Maintenant, si.»

La pièce vient de se voir ajouter un étage. C'est comme un choc. Mais on y voit toujours très clair. Et le groupe semble parfaitement confiant dans le fait que la structure peut continuer de s’améliorer.

Tu réalises maintenant que la mobilité des éléments dans cette pièce, cette flexibilité sans faille, est principalement due au fait qu’il y fait jour en permanence.

Le facilitateur annonce la fin du kata. On va conclure. Le facilitateur donne la parole à chacun.

- Pas mal. Nouvelle approche. Je la préfère à celle que je prenais avant pour résoudre ce kata. - On n’a pas traité les cas d’erreurs en entrée, finalement ! - Mais ce n’est pas grave… - J'ai apprécié le moment où tout s'est remis en place après qu'on découvre que les numéros de frames doivent entrer en ligne de compte… - Oui. Il y a deux steps pendant lesquels le design est tordu. - On pourrait faire mieux… - Est-ce qu'on a besoin de tous ces tests vraiment ? - Est-ce qu'on en a besoin, tu demandes ?! - Pas de refactoring sans tests. - Sans tests, on ne peut pas vraiment raisonner sur le code !

Tu redemandes à prendre la parole. - Excusez-moi, je ne connais pas bien TDD, mais il me semble que toute la journée je raisonne à propos du code que j'ai sous les yeux. Et il n'a aucun test. En tout cas, pas de test comme ceux que vous écrivez. Avez-vous déjà essayé cette approche, mais sans faire de tests ?

Le facilitateur sourit : - On a essayé une fois ou deux. C'est parti en vrille.

Quelqu'un lance : - Note que mob debugging ça pourrait être intéressant aussi. - Sans moi, répond une autre personne. Il n'y aurait pas assez d'action.

On se retrouve dans la rue, à la recherche d'un endroit où boire un verre. Tu décides de suivre le groupe. Tu as encore des questions à poser au facilitateur.

(à suivre) Episodes Précédents : 1 -- Si le code pouvait parler 2 -- Voir / Avancer 3 -- Communication Breakdown