Blog de Bruno Orsier

Un article de Bruno Orsier    3 Commentaires

Mercredi dernier je suis allé suivre une formation … euh donner une formation … participer à une formation ? C’est la difficulté quand on veut expliquer que l’on a assisté à un dojo de programmation ! En effet dans un dojo l’idée est plutôt d’apprendre quelque chose de manière collaborative. Donc c’était ce dojo, organisé dans le cadre du Club Agile Rhône Alpes par Rémy Sanlaville et Emmanuel Hugonnet.

Le but de ce dojo était d’apprendre le TDD (Test Driven Development, ou Développement Dirigé par les Tests) par la pratique, en réalisant la fonction d’évaluation nécessaire au jeu du Mastermind. Ce billet est un compte-rendu partiel (et partial, c’est ce qui fait le charme d’un billet !) des discussions très pertinentes qui ont eu lieu.

Avant de passer au compte-rendu, je voudrais souligner que j’ai bien apprécié l’introduction du dojo avec la phrase de Laurent Bossavit :

Si je veux apprendre le Judo, je vais m’inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j’aurai peut-être envie de pratiquer plus assidument.
Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004.

J’aime bien cette déclaration car elle illustre le décalage entre le besoin de formation pour devenir un développeur de bon niveau et entre les efforts que l’on y consacre en réalité. D’ailleurs, sur ce thème, il est intéressant de lire aussi l’essai « Teach Yourself Programming in Ten Years » de Peter Norvig (pour la petite histoire c’est l’un des auteurs du livre Artificial Intelligence: A Modern Approach qui était mon livre de chevet il y a une quinzaine d’années – maintenant ce monsieur est directeur de recherche chez Google). Dans son essai, Peter Norvig dit notamment :

Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again.

Bonne nouvelle, ces recherches semblent indiquer que la plupart d’entre nous peuvent arriver à un haut niveau, à condition de passer suffisamment de temps à pratiquer délibérément ! Pas besoin d’être un génie ou un surdoué au départ. Et même Mozart a dû travailler dur !

Les dojos de programmation de type randori sont en fait une bonne occasion de passer à cette pratique délibérée recommandée par Norvig. En effet, en nous obligeant à programmer en public, ils nous font sortir de notre zone de confort (le challenge) et nous permettent d’analyser, de corriger grâce au reste du groupe.

Voici maintenant mes commentaires sur certains aspects du dojo de mercredi.

La présence de plusieurs étudiants était très intéressante. On sentait bien qu’ils s’agitaient durant le démarrage, avec des réflexions du type « moi j’aurais déjà codé la solution du Mastermind », pendant que nous étions en train de batailler pour trouver un nom satisfaisant pour notre première méthode de test. En effet nous avons dû discuter pendant quelques minutes pour passer du nom de méthode initialement envisagé test1VertOk au nom testSecretVertCombinaisonVertReponseBienPlace1. Cet épisode a été l’occasion d’expliquer aux étudiants que dans un cadre professionnel (et encore plus dans un contexte agile à cause du réel travail d’équipe) on accorde énormément d’importance à la lisibilité du code car on va le maintenir de longues années. Rappelons à cet égard l’adage « n’importe quel idiot peut écrire du code compréhensible par un compilateur ; la véritable difficulté consiste à écrire du code compréhensible par d’autres personnes » – pour une plus longue discussion, voir Is Writing More Important Than Programming?

La question de savoir quand restructurer le code de test est venu constamment sur le tapis, sans que nous arrivions à une opinion tranchée. En tout cas mon avis personnel est qu’il faut restructurer tout le temps (à la fois le code de test et le code soumis aux tests), et de manière assez impitoyable. En fait il me semble même que le respect strict du principe DRY est vital pour comprendre la finesse du TDD, qui peut être beaucoup plus une activité de conception qu’une activité de test (ce sont les restructurations successives qui permettent d’identifier les entités et interfaces pertinentes).

Je pense que pour être convaincant sur le point ci-dessus il faut maîtriser parfaitement les outils de restructuration (refactoring) qui sont offerts par les environnements de développement récents. J’en suis d’autant plus persuadé après avoir assisté à la brillante démonstration de Régis Médina, et en voyant l’impact d’outils comme ReSharper sur certains de mes collègues. Cela nous a manqué dans le dojo car nous n’étions pas suffisamment au point sur NetBeans. Je pense aussi que dans l’organisation d’un dojo il faut insister sur le fait que l’objectif est également d’apprendre à mieux tirer parti de l’environnement de développement. Comme l’a suggéré mon collègue Luc après le dojo, il serait probablement intéressant d’organiser un dojo de type kata centré sur la maîtrise de ce type d’outils.

Pour illustrer la difficulté de convaincre sur ces aspects, voici un style de restructuration qui n’a pas rencontré une forte adhésion durant le dojo. Ayant constaté que certains tests étaient des copies les uns des autres (à certains paramètres de tests près) j’ai proposé d’extraire une méthode utilitaire pour les factoriser. Cela permet d’avoir des tests très condensés comme

Eh bien il y a eu beaucoup de discussions sur le bien-fondé d’introduire une telle méthode utilitaire. Et même parmi ceux que cela a convaincu, il y a avait une forte réticence à placer l’assertion de test directement dans la méthode utilitaire ! Et pourtant la ou les assertions font tout autant partie de la duplication de code que le reste. Apparemment mes propositions ci-dessus ont facilement permis a Emmanuel Hugonnet d’identifier mes sources d’influence, que j’ai vérifiées depuis, et Gerard Meszaros indique bien de mettre l’assertion de test dans la méthode utilitaire (cf. Parameterized Test sur son site web, ou encore dans son livre XUnit Test Patterns – Refactoring Test Code).

Tiens, tiens, le sous-titre de ce livre de référence est « Refactoring Test Code ». Ce n’est pas un hasard. Sans restructurations fréquentes, j’ai déjà constaté que le code de test devient difficile à faire évoluer, et contribue à fossiliser (et dans un mauvais état) certaines parties de logiciels. D’ailleurs ce thème a été discuté durant le dojo, avec des opinions de la forme « les tests unitaires sont pénibles à faire évoluer, donc il faut faire une conception initiale pour arriver tout de suite aux bons tests, et ne plus y toucher ». A ce stade vous devez vous douter que je pense à peu près le contraire ! Mon avis est en effet « restructurons le plus souvent possible, cela fera émerger une conception répondant exactement aux besoins ».  Si l’on maîtrise les bons outils, comme indiqué ci-dessus, il n’y aucune raison pour que les restructurations soient pénibles. L’extraction de méthodes utilitaires comme ci-dessus permet justement de restructurer encore plus facilement en réduisant le volume de code et en faisant apparaître des structures possibles.

Nous avons dû hélas terminer le dojo et ces discussions passionnantes alors qu’un autre point très intéressant se présentait. Il s’agissait de passer à un test portant sur quatre couleurs au lieu d’une seule, donc un test qui parlait de choses comme

new Combinaison(Couleur.BLEU, Couleur.JAUNE, Couleur.ROUGE, Couleur.BLEU)

Ce test ne parle pas de liste, de vecteur, de tableau… Mais la personne qui codait avait l’idée d’utiliser la classe Vecteur, et a donc commencé à écrire du code impliquant un Vecteur, puis a modifié le test pour faire apparaître un Vecteur ! Cela peut paraître subtil sans doute, mais cela nous a fait quitter le développement dirigé par les tests pour du développement dirigé par la conception ! Et c’est ennuyeux car rien dans le test (et donc dans le besoin utilisateur) n’exigeait de faire apparaître un Vecteur. D’ailleurs un Vecteur était-il plus approprié que d’autres structures de données ? Et notre interface de la classe Mastermind est maintenant liée à la classe Vecteur, alors que cette notion de Vecteur (si elle s’avère justifiée) pourrait très bien être encapsulée dans la classe Mastermind.

Après débat durant la rétrospective, nous avons décidé de faire marche arrière (heureusement tout de code produit était sous gestion de version) et d’annuler cette modification pour repartir du test initial.

En conclusion, un dojo très intéressant, où nous avons beaucoup discuté (peut-être trop par rapport au temps passé à coder) mais qui a permis d’aborder des questions très pertinentes sur le TDD. Vous pouvez accéder au code produit et à la rétrospective sur le site du CARA. Une prochaine séance aura lieu le mercredi 28 janvier.