Le Global Day of Code Retreat (GDCR) a eu lieu le samedi 18 novembre. J’y ai participé et je vous fais ici un retour sur mon expérience.
Pour ceux d’entre vous qui ne connaissent pas, le GDCR est un événement international durant lequel des développeurs se retrouvent pendant une journée. Le but est de travailler sur un exercice (nommé "kata") et de s’imposer différentes contraintes de développement. C’est l’animateur qui donne les instructions et peut éventuellement venir en aide aux participants. Tous les niveaux sont acceptés, avec toutefois quelques connaissances en développement. Lors de notre session, il y avait tout aussi bien des étudiants que des développeurs expérimentés.
À Bordeaux, l’organisation a été assurée par Okiwi, une association de Software Craftsmanship, et animée par Arnaud Lemaire.
Le déroulement de la journée
La journée de code retreat s'articule autour d'itérations de 40 minutes, à la fin desquelles tout le code réalisé doit être supprimé. De fait, on ne s’attache donc pas à une implémentation particulière d’une itération sur l’autre.
Dans notre cas, nous avons travaillé sur le "Game of life" : une grille infinie de cellules vivantes ou mortes, qui meurent ou subsistent selon l'état des cellules voisines.
À chaque itération, l'animateur ajoute des contraintes. Le tout se fait en TDD (Test Driven Development) et ping-pong pair programming :
- Un développeur écrit un test qui échoue.
- L'autre développeur écrit le code minimal pour passer le test au vert.
- Le même développeur remanie le code si nécessaire, puis écrit un test rouge.
- Le PC change de main, etc.
Il est aussi demandé de changer de partenaire à chaque itération. Comme le travail se fait en pair programming, cela permet d’aborder le sujet différemment. À la fin de chaque itération, les participants partagent leur expérience lors d’un stand-up.
Les contraintes imposées
Pour vous citer les sets de certaines contraintes que j'ai rencontrées lors de cette journée (dans l'ordre) :
- Aucune contrainte technique, mais obligation d'effacer le code couvert et les tests rouges toutes les 4 minutes (puis 3 et 2 minutes selon le temps d'avancement de l'itération). C’est l’occasion de s’échauffer et de s’habituer à passer le PC régulièrement, mais aussi de prendre les bonnes habitudes liées à la pratique du TDD.
- Impossibilité d'utiliser une grille pour gérer les états et evil-pair-programming : celui qui implémente doit faire preuve du plus de mauvaise foi possible. Cela oblige le testeur à orienter le développeur dans la direction qu'il souhaite. Dans ce cas, le PC ne change pas de main tant que l'implémentation ne satisfait pas le testeur. Il faut également utiliser son framework de test de façon peu naturelle.
- Absence de return et immutabilité facultative : cela nous a imposé une approche différente. Plus facile à mettre en place en Javascript, notamment grâce aux callbacks.
- Le real-time legacy code + pas de primitifs/collections (Pas de String, Integer, boolean, int, List, ArrayList …) : yeux bandés, impossibilité de communiquer avec le binôme. Cela oblige le testeur à formuler correctement son intention dans son test. De plus, il faut re-développer les structures soi-même, et utiliser des énumérations.
Il doit manquer certains sets de contraintes que nous avons "subis". Vous pourrez trouver d'autres idées sous le hashtag #gdcr17 sur Twitter. Il y a eu de nombreuses éditions en France.
Conclusion
Personnellement, c'était une expérience enrichissante. J’ai beaucoup appris, que ce soit sur l’amélioration de la qualité des tests ou la communication lors de sessions de pair-programming. C’était particulièrement le cas sur la session Real time legacy code, que l’on retrouve finalement dans notre vie de tous les jours. Le fait d’aborder la problématique en direct montre clairement qu’une intention bien exprimée dans les tests peut rendre la tâche du développeur plus simple.
Un autre enseignement tiré lors de la première itération, pendant laquelle nous avions un temps assez limité pour écrire nos tests, c'est le temps parfois important que peut prendre le remaniement de code. Nous avons également découvert à nos dépens qu'un code couvert à 100% n'est qu'une première étape vers un code fonctionnel, et couvrir à tout prix en nous dépếchant s'est rapidement retourné contre nous.
Le but de la journée n'était pas de produire un résultat, mais de découvrir des approches pas toujours évidentes dans le développement de tous les jours. C'est également l'occasion de (re-)découvrir le TDD et de vous donner envie de l’utiliser dans votre travail quotidien, si ce n’est pas déjà le cas.
J'espère que cet article vous aura donné envie d'y aller l'année prochaine. Les associations de software craftsmanship proposent également des coding dojos ou des conférences dans le même esprit : mise en pratique de TDD et Clean Code... N’hésitez pas à vous y rendre.
