Samedi 29 Septembre 2012, 8:30 AM, un groupe de personnes se réunit devant le 156 boulevard Haussman. Non, il ne s’agit pas d’une réunion clandestine :). Toutes ces personnes sont là pour participer à une journée de code retreat.
Le principe du code retreat
Ouvert à tous et toutes, le code retreat a été conçu par les développeurs pour les développeurs. Basés sur les principes des Coding Dojo, un code retreat dure quant à lui une journée entière. C’est un événement lors duquel le pair-programming, le design de code, le « beau » code sont mis en avant. Un code retreat peut aussi être l’occasion de découvrir d’autres langages, puisqu’aucune contrainte de langage n’est imposée. Lors de ce code retreat, nous avons codé en javascript, scala, erlang, ruby, haskell et smalltalk.
Un exercice de code est choisi par les animateurs, le plus connu étant « Le Jeu de la Vie ». Tout au long de la journée, les participants en pair-programming codent l’exercice lors de plusieurs itérations de 45 minutes chacune. Chaque itération est suivie d’une rétrospective commune de 15 minutes et d’une petite pause de 5 minutes.
Après chaque itération, les participants sont encouragés à changer de binôme. De plus, le code produit lors de la précédente itération est supprimé afin de repartir à zéro à la nouvelle itération.
En général entre 5 et 7 itérations sont faites dans la journée, avant de terminer par une rétrospective globale.
L’arrivée – les croissants
Les organisateurs, Jean-Laurent De Morlhon et Laurent Bossavit, nous ont accueilli dès 8h30 puis convié à un petit déjeuner très équilibré composé de croissants, pains au chocolats et autres viennoiseries bien nécessaires pour affronter cette matinée.
Après nous avoir expliqué les règles du jeu, Jean-Laurent et Laurent, nous ont invité à « ouvrir notre esprit », autrement dit :
Les premières itérations
Voici les quelques règles de Simple Design que nous avons essayer de mettre en oeuvre lors des différentes itérations:
Pause déjeuner
La pause déjeuner a été l’occasion de nous connaître un peu plus, de partager nos expériences dans nos missions, de revenir sur les algorithmes/solutions trouvés pour implémenter « Le Jeu de la Vie », ou encore de regarder des vidéos geek.
Pizzas et Pause Déjeuner
Pour les itérations de l’après-midi, Laurent et Jean-Laurent nous ont proposé de rajouter des contraintes : nous avons notamment essayé la technique TDD Ping-Pong à l’aide du plugin eclipse PairHero, rendant au passage le binômage un peu plus ludique.
La leçon à retenir: il faut bien entendu communiquer, mais il est également très important d’aller à l’essentiel.
Rétrospective de la journée
Pour conclure cette journée, chaque participant a répondu aux questions suivantes:
Rétrospective de la journée
Conclusions
Un code retreat est un très bon moyen d’apprendre à coder proprement, de se confronter à d’autres approches, façon de penser via le pair-programming. C’est aussi l’occasion de tenter ce que l’on n’ose pas dans nos missions et d’essayer d’autres langages.
N’hésitez pas à participer aux prochains code retreat, quelques soient vos connaissances, votre expérience et vos langages de programmation !
Le 3 Décembre 2011 a eu lieu le Global Day of Code Retreat où plus de 2200 développeurs se sont retrouvés le temps d’une journée dans plus de 90 villes du monde , simplement, pour écrire du beau code…
En France, seulement trois Code Retreat ont été organisés à l’occasion de cette journée:
– un à Paris dans les locaux de Xébia
– un à Bordeaux dans les locaux d’Arpinum
– et un à Toulouse dans les locaux de DocDoku
Connaissant déjà les Coding Dojo, j’étais curieuse d’en savoir plus sur les bienfaits d’un Code Retreat que l’on m’avait décrit comme une journée de code composée de 5 ou 6 itérations de 45 minutes ; chaque itération étant consacrée à coder le même problème dans le langage de son choix… et tout cela en prenant bien soin à la fin de chaque itération d’effacer le code écrit et de changer de binôme !
Et c’est surtout ce point qui m’intriguait : effacer et recommencer à coder….mais pourquoi ?
C’est donc, avec une certaine curiosité, que j’ai rejoint dès 8h30 du matin les 15 autres participants de ce premier Code Retreat toulousain. Là, j’ai pu constater qu’un des premiers mérites du Code Retreat avait été de regrouper des habitués de plusieurs User Group toulousains : Toulouse JUG , Apéro WEB , et les agilistes de la SigmaT
Après un café, Antoine, notre animateur du jour (“facilitator”) nous a présenté le déroulement de la journée, mais surtout le problème à coder qui n’était autre que le jeu de la vie (Game of Life). Le jeu de la vie est un automate cellulaire imaginé par John Horton Conway en 1970. L’univers du jeu de la vie se déroule sur une grille à deux dimensions, théoriquement infinie. Chaque cellule a 2 états possibles vivante ou morte. À chaque étape, l’évolution d’une cellule est entièrement déterminée par l’état de ses voisines. Les règles suivantes nous ont été proposées :
Cette journée étant consacrée au code, il était donc fondamental de rappeler également les 4 règles élémentaires requises pour écrire du code de qualité :
Un des principes du Code Retreat est que chaque participant vienne avec un ordinateur portable sur lequel il a installé au moins un environnement de développement de son choix (comprenant bien sûr une libraire de tests unitaires…).
Les itérations se déroulent ensuite en pair-programming (en binôme) où le ping pong est encouragé :
La présentation terminée, il était grand temps de découvrir les langages du jour. La plupart des participants étaient venus avec un environnement Java, mais il était également possible de développer en C++, Python, C#, Php et même Javascript.
Tout était dit. La première itération de code pouvait être lancée !
Les binômes se sont rapidement formés au hasard et le marathon des six itérations a pu commencer…
Première itération : Installation & Compréhension du problème…
Cette première itération sert en quelque sorte d’échauffement pour la suite de la journée.
Après l’installation des binômes et le lancement des environnements de développement vient le temps de la réflexion et de l’analyse du problème donné. On commence alors à s’approprier les règles du jeu de la vie, à griffonner un diagramme d’états, puis le code peut enfin s’exprimer. Dans cette première itération, nous avons choisi d’implémenter l’univers du jeu de la vie de manière très simple (tableaux à deux dimensions) afin de s’intéresser au plus vite aux règles métier. Aucune consigne n’avait été donnée pour cette itération, à part le respect du ping pong. Mais 45 minutes passent très vite (trop vite) et c’est vraiment lorsqu’on commence à être un peu productif, à rentrer dans le vif du sujet, que l’on doit s’arrêter. Et oui, c’est déjà fini… Au bout de ces premières 45 minutes, l’application est loin d’être terminée et le code écrit pas vraiment optimisé.
Je dirais que cette première itération sert de défrichage et permet de se mettre dans l’ambiance de la journée.
Chaque itération est ensuite suivie d’une rétrospective de 15 minutes animée par le “facilitator”.
A la fin de la rétrospective, Il faut respecter une des règles d’or du Code Retreat : effacer le code produit au cours de l’itération. Cela est un peu déroutant la première fois. Donc ce n’est pas sans quelques réticences que nous avons supprimé notre code, mais c’est la règle !
Deuxième itération : Vers une conception Objet mieux pensée …
Chaque itération donne l’occasion de coder avec une nouvelle personne, les binômes devant être recomposés à chaque fois. Il est même possible de changer de langage d’une itération à l’autre …
Avant chaque itération, une nouvelle consigne est donnée par l’animateur afin d’encourager une création différente à chaque fois. La première rétrospective avait montré que la plupart des binômes était partie sur un tableau pour implémenter rapidement l’univers du jeu de la vie. Dans cette deuxième itération, la consigne donnée était donc de penser plus Objet en terme d’Univers et de Cellule…
Dès cette deuxième itération, j’ai pu constaté que l’écriture du code était beaucoup plus fluide, moins hésitante, plus rapide. Le code produit à l’itération précédente était naturellement repensé et optimisé pour la nouvelle itération. Le fait d’effacer le code permettrait-il alors vraiment d’écrire du code différent et plus performant d’itération en itération ?
La consigne étant l’Objet, notre binôme a cependant beaucoup discuté lors de cette itération sur la manière de prendre en compte le caractère extensible du problème (cellules à n facettes, univers à n dimensions) pour finalement convenir avec l’animateur que nous resterons par la suite seulement dans un espace à deux dimensions. Avons-nous perdu notre temps ? Je ne pense pas car nous avons pu mener une réflexion commune. Et cela fait également partie de la magie du Code Retreat de pouvoir s’adapter immédiatement à son binôme, de pouvoir partager ses points de vue, ses bonnes pratiques de code et ses astuces de programmation.
A la fin de cette deuxième rétrospective, il n’a pas fallu déroger à la règle de base du Code Retreat qui consiste à supprimer définitivement le code, et cette fois-ci c’est même avec un certain plaisir que chaque binôme a effacé son code !
Troisième itération : No For, No if …
La consigne de la troisième itération était de n’écrire ni boucle, ni test : “No for, No if” devait désormais être notre devise. Je n’avais jamais envisagé avant d’écrire un programme Java sans for, ni if (ni while, ni switch) et je dois dire que cette consigne nous a laissés perplexes pendant un certain temps : pas vraiment évident de respecter une telle consigne …
Certains binômes ont essayé de contourner la contrainte en dissimulant dans leurs instructions des tests via des opérateurs binaires et ternaire (&&, ||,?), d’autres ont évoqué le pattern Visiteur.
La notion de récursivité est également venue naturellement à l’esprit dès lors que les boucles n’étaient pas permises. Mais classiquement, qu’est-ce qui stoppe une récurrence ? Une condition d’arrêt que l’on écrit généralement avec un if !…Et hop, il est encore nécessaire de pousser la réflexion un peu plus loin. Ce test conditionnel peut alors être évité en faisant appel à des notions de polymorphisme. Vincent propose dans son retour un exemple de code pour illustrer cette solution.
Personnellement, c’est l’itération de la journée que j’ai préférée. Ecrire un code sans structure de contrôle est une contrainte qui ne me serait jamais venue à l’esprit…et pourtant au final, on constate que c’est un excellent exercice pédagogique !
A la fin de la troisième itération, il était déjà plus de midi : l’heure de la pause déjeuner.
Le repas fait intégralement partie du concept du Code Retreat : c’est un moment convivial d’échanges entre les participants. Il est donc important de prendre une vraie pause repas d’environ une heure et demie. Le repas est généralement offert par le sponsor de l’événement. Merci DocDoku !
Quatrième itération : Tell don’t ask, no primitive obsession …
La consigne de la quatrième itération était de respecter le principe Tell don’t ask. Ce principe de connaissance minimale consiste à demander directement à un objet ce qu’il doit faire, plutôt que de l’interroger sur son état interne afin de prendre des décisions qui mènent à des actions de sa part… Autrement dit, les getters/setters devaient cette fois-ci être bannis de notre code, et les méthodes judicieusement choisies et nommées en fonction de nos besoins.
Le principe Tell don’t ask imposé dans cette itération devait également nous amener à repenser notre code en évitant toute “primitive obsession” c’est-à-dire que nous devions éviter d’utiliser des types primitifs comme attributs (autant que possible).
Durant cette itération nous nous sommes donc plus particulièrement intéressés aux cellules, à leurs coordonnées, et à la notion de voisinage ? La Cellule doit-elle connaître ses coordonnées ? La Cellule doit-elle connaître ses voisins ? Ne serait-il pas plus judicieux que l’Univers gère lui-même la notion de voisinage ? etc …
De nombreuses questions qui devaient nous amener à écrire un nouveau code “tout objet”, vraiment très différent de celui de la première itération.
Cinquième itération : Itération sans parole …
La cinquième itération fut une itération qui se déroula sans bruit, puisque la consigne consistait à interdire aux membres d’un même binôme de parler entre eux. Seuls les tests, écrits de manière expressive, devaient permettre de révéler les intentions de l’un et de l’autre. Sans discussion préalable possible, cette itération, bien plus que les précédentes, demandait de porter une attention particulière à l’expressivité du code pour que chacun puisse comprendre l’attente de l’autre. Il fut indispensable de nommer les méthodes de manière très significative, ce qui nous amena bien souvent à écrire de véritables phrases pour nommer les méthodes des classes de test .
Cette itération fut une itération assez difficile à mener. En effet, arrivés à la cinquième itération de la journée, chacun a avancé dans sa vision du problème en menant au cours de la journée ses propres réflexions avec des binômes différents. Et bien que les contraintes de chaque itération soient communes, les choix de conception et d’implémentation sont parfois bien différents. Ce fut le cas pour cette itération où avec mon binôme nous avions deux approches différentes, ce qui compliqua la tâche mais nous incita doublement à écrire des tests expressifs afin d’essayer de trouver une solution commune.
Sixième itération : A La Carte …
La sixième et dernière itération était une itération “à la carte” destinée à se faire plaisir où chaque binôme pouvait choisir une consigne parmi les propositions suivantes :
(1) Une discussion a depuis été lancée sur la mailing list du Toulouse JUG !
Rétrospective finale
Lors de la rétrospective finale chaque participant a dû répondre aux 3 questions suivantes :
Les expériences des participants étaient diverses, mais chacun s’est accordé pour dire :
La journée s’est terminée par l’annonce de la création d’une communauté Software Craftsmanship sur Toulouse qui, espérons-le, proposera très prochainement d’autres Code Retreat !
Liens :
http://globalday.coderetreat.org/
http://jduchess.org/duchess-france/blog/resolutions-2011-coding-dojo-code-retreat/
http://coderetreat.com/gol.html
http://c2.com/cgi/wiki?XpSimplicityRules
http://coderetreat.org/facilitating/structure-of-a-coderetreat
http://coderetreat.ning.com/profiles/blogs/how-a-coderetreat-works
http://pragprog.com/articles/tell-dont-ask
https://groups.google.com/forum/#!topic/toulouse-jug/SpOWtYPxJa0
http://antoine.vernois.net/dotclear/index.php?post/2012/01/09/Software-Craftsmanship-%C3%A0-Toulouse
Autres retours sur le Global Day of Code Retreat :
http://blog.genigraph.fr/2012/01/03/code-retreat-de-toulouse-le-03-decembre-2011/
http://blog.r0ly.fr/?p=67
Des Photos du Code Retreat toulousain
https://plus.google.com/photos/116856815308605996307/albums/5682276859165947169
En début d’années on prend des tas de bonnes résolutions. La résolution de cette année 2011 sur le plan professionnel pourrait être “Et si je m’entraînais à coder” ? OK, je sais déjà coder, mais si je m’entraînais pour m’améliorer ?
Une citation de Laurent Bossavit exprime bien l’idée :
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 assidûment.
Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004.
Cherchez l’erreur.
Laurent Bossavit
Le dojo est comparable a un entraînement. Les sportifs, les musiciens s’entraînent pour apprendre de nouvelles techniques et simplement rester au niveau. Les informaticiens sont dans un environnement très changeant en matière de technologie et de pratiques et ont besoin d’apprendre et de se tenir à jour. Comment mieux comprendre une technologie, une méthode, des pratiques qu’en les voyant mises en oeuvre dans la résolution d’un problème concret ?
Concret certes, mais le but du dojo n’est pas de trouver une solution a tout prix. Le but est de trouver une belle solution, de montrer sa réalisation pas à pas pour la faire comprendre et partager, d’échanger avec le reste du groupe sur les points forts et les points faibles de cette solution. C’est quelque chose qu’on a rarement le temps de faire dans un milieu professionnel où il faut répondre le plus vite possible au problème. Le dojo est un environnement sûr où on peut expérimenter des démarches différentes, apprendre un nouveau langage.
Découvrir, apprendre, et consolider ces connaissances jusqu’à ce qu’elles deviennent des réflexes. Perdre ses mauvaises habitudes de code pas beau. Parvenir à raisonner par défaut avec une démarche pas à pas, vérifiée à chaque étape, c’est à dire TDD (développement dirigé par les tests) et ne pas retomber dans le bidouillage cradouille à chaque fois que l’on fait face à une difficulté. Croyez moi, ce n’est pas facile, la pente du “je fais marcher, on verra après” est assez tentante, et pas mal glissante aussi au bout de quelques étapes.
Mais le dojo est un groupe et il vous rappelera à l’ordre si jamais vous avez quelques tentations. L’organisation en groupe rend cet apprentissage plus intéressant. Il permet de rencontrer d’autres passionnés ou simplement des gens curieux. Mais c’est aussi un moyen de travailler sa technique de travail de groupe : être suffisament discipliné pour ne pas interrompre la présentation à tout bout de champ, savoir expliquer ses arguments sans agressivité, savoir recevoir les critiques et les prendre en compte.
Il faut aussi savoir donner. Il n’y a pas de speaker qui va vous apprendre des choses. Chacun participe d’une certaine manière.
Au final, le dojo se doit d’être ludique pour maintenir la motivation. On ne va pas implémenter des règles de gestion de commandes ou d’attribution de crédit. Les sujets de coding dojo sont en général sans utilité réelle et conçus dans un but ludique.
L’écoute est importante. Les coding dojos commencent souvent par une rétrospective du dojo précédent. Pour partager avec ceux qui n’ont pas pu venir et c’est souvent l’occasion de faire le compte rendu. Le retour porte sur l’exercice, l’explication dans les grandes lignes de la solution apportée mais aussi sur ce qui s’est bien ou mal passé du point de vue de la démarche : des étapes sautées dans la démonstration qui l’on rendue difficile à comprendre, des gens dissipés, mais aussi une pratique que l’on a bien apprécié et que l’on tr ouve utile. Le débrieffing a froid permet de réduire les tensions et d’avoir envisagé des solutions dans l’intervalle.
Il faut ensuite choisir un sujet. Il n’y a pas de speaker qui vient avec un sujet préparé. Le groupe choisi un des exercices proposés par les membres du groupe.
Il y a deux grands types d’exercices :
Les randori permettent à chacun de mettre les mains dans le code et de s’impliquer. C’est toutefois un peu difficile si les gens ne connaissent pas du tout le langage ou la technologie utilisée. Un autre apport du randori est de travailler sa souplesse. La solution a pu être commencée avec un algorithme qui n’est pas celui que vous auriez choisi. Il faut savoir s’adapter. Il faut aussi savoir remettre en cause ce choix s’il ne mène à rien et le remplacer.
Dans les deux cas, celui qui présente son kata ou est dans son tour de randori doit avoir l’attention de tous. Il ne doit pas être interrompu pendant qu’il présente sa solution et met en oeuvre une étape de sa résolution, jusqu’à la barre verte. La barre verte est l’affichage de la plupart des outils de test unitaire pour montrer que tous les tests passent. Lorsque la personne réfléchi à sa solution et l’implémente, on la laisse se concentrer. Lorsque la barre est verte, on peut discuter des choix réalisés et si nécessaire les remettre en cause. Bien sûr, si la personne est en difficulté, elle peut être aidée à tout moment.
L’exercice dure environ 1h.
Le TDD est indispensable dans ce genre d’exercice car il permet de rendre la main régulièrement au groupe pour avoir un retour. Les langages sont souvent des langages nouveaux et fonctionnels (Ruby, Scala, Haskell, …) car ils sont plus motivants.
Vous pouvez imaginer des problèmes amusants qui peuvent être résolus en 1h environ. Écrire un convertisseur de chiffres romains est un bon exemple de défi raisonnable. Si vous manquez d’imagination, des sujets types sont présentés sur ces deux sites :
On part d’une page blanche en général car le but est de tout expliquer pas et pas. La recopie de gros bouts de code amenés dans ses cartons se prête mal à l’exercice. Il existe toutefois des variantes où on part d’une situation donnée issue d’une séance précédente ou dans le but de s’exercer à faire du refactoring.
La session se termine par un debrieffing rapide sur ce qu’on a fait.
Et maintenant, il vous faut trouver un groupe près de chez vous :
Si vous connaissez d’autres coding dojos actifs, n’hésitez pas à nous tenir au courant.
Il n’y en a pas et vous voulez vous lancer ?
Pour que tout se passe bien :
Et probablement qu’au début vous aurez à fournir vous même beaucoup des sujets pour qu’il y en ait au moins un 
Arrivera un jour où votre entrainement hebdomadaire ne suffira plus. Vous aurez envie d’aller plus loin.
Une heure c’est un peu court. On n’a pas vraiment le temps d’explorer différentes solutions ou de mener jusqu’au bout certains exercices.
Cette année on voit apparaître des “code retreats“, des retraites dans un lieu sympa, entre développeurs pour coder une journée entière ou un Week End entier selon les formules.
C’est l’équivalent des stages complémentaires pour les gens qui pratiquent un sport, l’occasion de rencontrer un peu plus longtemps les plus motivés, de rencontrer des experts.
Le premier code retreat a été organisé à Grenoble par l’AlpesJUG le 21 Janvier. Il a été dédié à l’implémentation par plusieurs équipes du jeu de la vie un classique des coding dojos.
D’autres suivront probablement, soyez attentifs.
J’ai utilisé différentes sources pour réaliser cet article :
Vous pouvez aussi regarder ces documents :
Merci à Isabelle Blasquez pour la relecture et les informations complémentaires.
les 24 et 25 mai à Lyon
En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations
Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.