Cyber dojo au Software Craftsmanship 2011

La conférence Software Craftsmanship 2011 – à propos de laquelle deux billets ont déjà été publiés : How Object-Oriented are you feeling today ? et Lean code challenge – s’est clôturée avec la session dite du Cyber dojo, inventé, programmé et présenté par Jon Jagger.

Le Cyber dojo est un exercice d’apprentissage dans lequel les participants peuvent pratiquer l’écriture de logiciel en « entraînement intentionnel » (deliberate software practice).

L’entraînement intentionnel c’est lorsque l’on cherche à améliorer sa capacité à réaliser une tâche. On parle de technique, d’habileté et surtout de répétition. On réalise donc une tâche dans le but d’améliorer la maîtrise d’une ou plusieurs parties de la réalisation de cette tâche. Cela implique un grand nombre de répétitions, jusqu’à ce que l’on atteigne le niveau de maîtrise désiré. On pratique l’entraînement intentionnel dans le but de maîtriser la tâche à accomplir, non dans l’unique but de l’accomplir.

Le Cyber dojo est particulièrement adapté pour travailler la collaboration entre les équipes et le TDD. L’originalité de l’exercice est que l’ensemble des participants soumet son code à un serveur central qui exécute les projets et garde une trace de ces exécutions.

Les participants travaillent en petits groupes. Chaque groupe travaille sur un seul ordinateur :

• en écrivant le code et les tests associés dans un navigateur ;
• en les soumettant au serveur de CyberDojo aussi souvent qu’il le désire. Le serveur exécute alors le projet et retourne le résultat des tests au navigateur.

Le serveur de CyberDojo permet d’exécuter du code dans plusieurs langages : C, C++, C#, Java, Javascript, Objective C, Perl, PHP, Python, Ruby.

Premier round

Nous avons donc pris en main l’interface du Cyber dojo et nous étions assez peu enthousiastes à l’idée d’écrire du code dans un navigateur, d’autant que l’éditeur est… frustrant. Pas de compilation à la volée, pas de complétion.

Nous nous sommes cependant prêtés au jeu, et avons abordé la lecture de l’énoncé de l’exercice. Il s’agit du kata nommé « Les chiffres romains », un kata populaire qui consiste à retourner un nombre décimal correspondant à une chaîne de caractères en numération romaine. ( III -> 3, XV -> 15, etc…)

Nous avons eu pas mal de difficultés à démarrer. Après avoir réussi à écrire un test qui échoue, nous avons voulu écrire le code nécessaire pour faire passer ce test, en bons praticiens du TDD. Mais nous nous sommes heurtés à l’âpreté de l’IDE et nous avons commis une bonne série d’erreurs de compilation. À chaque essai nous soumettions notre code au serveur qui invariablement nous relevait des erreurs de syntaxes (feu orange).

Le serveur garde trace de toutes les exécutions et symbolise par des feux de couleur les résultats. Rouge : Tests en échec, Orange : Erreur de compilation, Vert : Test réussi. Le Cyber dojo assigne aussi un « avatar » sous forme d’animal à chaque participant ; après notre série d’échecs de compilation le serveur affiche au yeux de tous les participants notre série :

Nous avons ensuite ajouté quelques fonctionnalités les unes à la suite des autres, toujours en suivant la pratique du TDD. J’écris un test qui met en œuvre la fonctionnalité désirée et qui échoue, je passe le clavier à mon co-équipier qui va écrire juste le code nécessaire pour que le test passe, puis ce dernier écrit un nouveau test qui échoue avant de me passer le clavier.
Nous avons obtenu après quelques courtes itérations le schéma suivant :

Nous avons ensuite trouvé que notre code demandait pas mal de refactoring pour pouvoir continuer sereinement. Le refactoring consiste à modifier le code sans que cela affecte les fonctionnalités, nous nous assurons que c’est le cas en exécutant les tests à la suite de chaque changement.
Nous obtenons le résultat suivant :

Pendant toute la durée de l’exercice nous avons pu consulter aussi où en étaient les autres joueurs. Sur le mur étaient projetés les resultats de l’ensemble du dojo. Notez que le serveur garde également trace, comme un gestionnaire de version, de l’ensemble des soumissions. En cliquant sur l’un des feux, on retrouve le code soumis à cet instant. Dans la vue suivante, notez que les « temps morts » durant lesquels nous ne soumettions pas de code ont été supprimés (il existe 2 vues et je n’ai pris des screenshots que dans ce mode). Nous avons tous fini l’exercice ensemble, l’équipe avec un zèbre pour avatar a juste soumis un peu plus de code que les autres participants.

A noter que sur l’interface web nous pouvions diffuser des messages courts à la vue de tous, pour demander de l’aide ou échanger avec les autres. Vous pouvez voir dans la vue suivante, l’interface de saisie. Dans la partie de gauche une section permettant de renommer/ajouter des fichiers ainsi que le script de build et dans la partie de droite notre code, en l’occurrence celui que nous avons écrit en 20 minutes à deux.

Second round et conclusion

À la manière d’une code retreat nous avons ensuite changé de co-développeur et remis à zéro notre IDE.
Nous nous sommes livrés au même exercice mais en ayant une approche différente. Dans notre cas, nous avons décidé, plutôt que de prendre les tests dans l’ordre croissant des nombres (1, 2, 3, 4, 5…), de les prendre en fonction de ce qui nous semblait être les étapes clés à résoudre (1, 5, 10, 9, 11, 15…).
Dans le même temps imparti, notre code final était trés different, bien moins naïf, et nécessitait probablement moins de refactoring. TDD ou pas, il faut bien penser à ce que l’on veut faire à l’avance, et la vieille rengaine qui énonce qu’il faut prendre quelques minutes pour réfléchir à ce que l’on va faire avant de commencer à toucher le clavier est toujours d’actualité. Cependant, à une conférence sur le craftsmanship c’est finalement le genre de leçon que l’on est en droit d’expérimenter.

La répétition nous a permis d’améliorer sensiblement notre design, et une troisième itération aurait été la bienvenue car nous avions encore quelques idées pour améliorer notre programme. Nous avons partagé tout cela avec le groupe, les uns après les autres, sous la forme d’une retrospective d’exercices.

Cette session clôturait une grosse journée de conférences pas comme les autres, durant laquelle nous avons réellement mis en pratique beaucoup de techniques et avons eu le sentiment de découvrir une autre manière « d’apprendre à apprendre ». Nous étions au départ surpris par le faible nombre de sessions – 4 pour toute la journée, mais de 90 minutes chacune – mais cela semble au final largement suffisant. L’intensité est bien plus élevée que lors de keynotes durant lesquels nous sommes plutôt passifs. Une journée finalement excessivement pratique, aux antipodes du feeling marketing que l’on peut parfois voir derrière le terme de craftsmanship si on ne se donne pas la peine de gratter la surface.

Quelques liens pour creuser le sujet :

• CyberDojo : http://jonjagger.blogspot.com/p/cyberdojo.html
• Deliberate Practice : http://jonjagger.blogspot.com/2011/02/deliberate-practice.html
• CyberDojo Source Code : http://github.com/JonJagger/cyberdojo
• Le Kata RomanNumeral : https://github.com/xebia-france/romannumeral-kata