Code retreat : de l’autre coté de la barrière !

2011 a été une année particulière, vous avez certainement vu vos twitters s’agiter sur le tag #codeRetreat ! En apogée, le 3 décembre 2011, près de 80 villes ont contribué au Global day of Code Retreat.

En quelques mots, le code retreat a pour objectif de “lever la tête du guidon” et de poser la réflexion sur nos pratiques de codage. Le but est d’explorer des voies, des techniques, et non le livrable développé.

En complément des différents retours de la blogosphère et en prémisse du legacy code retreat du 12 mai à ProxiAD, je vous propose de découvrir l’événement, du point de vue du facilitateur. Je remercie Adrian Bolbocoa, de m’avoir offert cette possibilité !

TDD as if you meant it

Première session

La première session constitue l’échauffement. Aucune contrainte.
L’idée est de se plonger dans le problème : le Jeu de la vie (GameOfLife).

Après 45 minutes, un “delete your code now” résonne dans la salle, il est temps d’effacer son code.

Les réactions se font vives “Quoi !” “Comment ?”, “Mais on ne va jamais avancer si on efface tout à chaque fois”.
Les frustrations sont logiques, mais l’objectif n’est pas de terminer l’exercice. Il s’agit d’identifier ce qui nous a posé problème :

  • Trop court, mais pourquoi ?
  • On ne sait pas comment commencer, mais pourquoi ?
  • Je n’ai rien codé, mais pourquoi ?
  • Des difficultés avec l’IDE ? Une démarche peu efficace ? Un mauvais angle d’attaque? Le problème auquel nous nous sommes attelés était disproportionné ?

Lors de la rétrospective, le groupe est timide, la frustration est marquante.

Durant cette session nous avons remarqué que certains ne connaissent pas les techniques de test, que le code contient de la duplication, que les méthodes font plusieurs choses, et que finalement les discussions sont vives mais peu de code est écrit !

Session 2

Nous pouvons alors, soit améliorer les échanges au sein des binômes, par un pair programming game, ou introduire certaines guidelines de développement.

Nous optons pour la deuxième option avec “4 rules of design“.
1. Passes its tests
2. Minimizes duplication
3. Maximizes clarity
4. Has fewer elements

Nous aurions pu utiliser les principes SOLID que j’affectionne particulièrement, mais certains concepts impliquent une présentation plus poussée, ici nous cherchons à pratiquer.

Comme le font remarquer certains, ces éléments peuvent paraître dogmatiques, mais l’idée est de se questionner, de justifier ses choix, de prendre le sens du détail.
L’exemple typique est celui de l’interface IQuelquechose, ou des implémentations du style QuelqueChoseIMPL…

Pourquoi fait-on cela ? Est-ce que cela a un sens ?

Une autre dynamique se met en place, les gens se creusent la tête.
La session s’écoule, la rétrospective montre que certains participants lèvent le voile sur le “vrai” TDD.

Session 3

Nous observons toujours que les binômes ne “pair” pas vraiment, beaucoup de discussions, pas trop d’actions. Nous proposons alors les contraintes suivantes :

  • Ping-pong pair programming : une personne écrit un test qui échoue, l’autre le fait passer et ecrit un test qui échoue, et ainsi de suite.
  • No conditionals : ne pas utiliser de if/else
  • Silent programming : on ne doit pas parler
  • No loops : pas de boucles
  • Methods of 4 lines max : forcer à faire des méthodes qui ne font qu’une seule chose.

Les participants peuvent choisir une, plusieurs ou toutes les contraintes !
45 minutes plus tard, plusieurs des participants nous indiquent avoir apprécié le jeu de ping pong et comprendre la dynamique qui se cache derrière le TDD. C’est une première victoire, très satisfaisante !

D’autres se sont essayés au “no conditional”, et y ont réussi en remplaçant la comparaison par le dispatch [objet d’un futur article].

Il est temps de faire une pause. Les discussions animées me donne le sentiment que “la sauce a pris”.

Session 4

C’est avec le sourire que nous abordons l’après-midi. Les tests du matin étaient  plutôt lourds. Il est temps pour tout le monde d’apprendre à faire de plus petits pas : nous mettons en œuvre “Baby Steps”.
Nous nous reposons ici sur git, toutes les deux minutes, nous réinitialisons le code au dernier état du dépôt.
Si les travaux entrepris pendant n’ont pas permis d’aboutir à un test vert, il est perdu, sinon, il est commité.

45 minutes s’écoulent. Certains sont passés sur des intervalles de 5 minutes.
D’autres ont changé de stratégie et font de plus petites étapes.

Session 5

Nous pouvons maintenant attaquer les choses sérieuses, et faire l’atelier qui est généralement le plus perturbant : TDD as if you meant it !
L’idée est de focaliser sur le comportement et de s’abstraire de toute conception : L’implémentation doit se faire dans le test, toute extraction de méthode, création de classe ou autre doit se faire par refactoring.
Le plus perturbant est le démarrage : il faut trouver le “baby step” qui permet d’avancer.

Comme je l’imaginais, les participants sont face à leur première méthode de test, et il faut trouver le comportement qui ne soit ni trop simple ni trop compliqué.
Le point d’entrée de l’application d’une règle est assez simple, je guide donc certains des participants la dessus.

Voici 5 sessions écoulées et plusieurs propositions pour la dernière :
– 1 heure pour aller plus loin dans le développement et lever la frustration du “delete your code now”
– une session de 45 minutes pour introduire une 7ème session (le record est Madrid avec 9 sessions!)

L’avis général est de partir sur une session d’une heure, le sujet est libre, les personnes peuvent reprendre les contraintes de la journée.
Julien introduit Object calisthenics, et je vais prendre plaisir à coder avec lui sur cette session, sous l’œil attentif d’Adrian.

Rétrospective

Tout le monde a trouvé cette journée très riche en apprentissage, en découverte et sur le plan humain.
Beaucoup de langages (Ruby, SmallTalk, Php, Java, C#), et de pratiques différentes ont été utilisés. Ce sont autant de possibilités de découvrir, approfondir ou de prendre une bonne piqûre de rappel.

Beaucoup sont surpris de l’apport de cette journée, ou des réflexions qu’elle peut amener.
Certains comprennent la dynamique du TDD, pour d’autres la pratique paticulière « TDD as if you meant it » a livré ses secrets.
Beaucoup d’entre eux ont été perturbés, ou gardent une certaine frustration. Beaucoup sont prêts à modifier leur façon de travailler, et à mettre en œuvre ces pratiques dès le lundi suivant.
Des questions de fond sont toujours là : quand créer une classe ou non, …
La session git a convaincu, je pense que cette dernière sera une clef lors des autres code retreat ! Certains voient déjà l’intérêt d’utiliser les pomodoros dans cet esprit.

Merci Adrian et Erik pour cette trouvaille !

Retrouvez les photos ici : http://coderetreat.org/photo/photo/slideshow?albumId=6456126:Album:7620

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">