Les coding dojos expliqués par VISEO 

Les méthodologies

Le principe du TDD (Test Driven Development) est de développer les tests avant d’implémenter le code qui répond à ces tests. Cela se fait en trois étapes :

1. Ecrire un test rouge (qui ne passe pas, normal, le code actuel n’est pas censé y répondre, on développe une nouvelle fonctionnalité)
2. Développer la fonctionnalité le plus facilement possible pour faire passer le test (vert), sans casser les autres tests potentiellement existants.
3. Effectuer un refactoring du code afin de le rendre plus lisible (en s’appuyant notamment sur les principes du Clean Code)

Dans un coding dojo, nous allons essayer de faire du TDD en implémentant successivement les plus petites améliorations possibles (principe de baby step). Par exemple dans un coding dojo visant à traduire des nombres romains en chiffres arabes, on commencera par tester le ‘I’, puis implémenter la plus petite solution possible au problème actuel, sans se projeter dans l’avenir et penser à comment traduire ‘MMCXLIV’ (2144). Puis, une fois la solution trouvée on passera au test du ‘II’ et ainsi de suite.

Le but de la partie refacto est, entre autres, de réduire la duplication de code et de pattern de code (DRY). Le principe que je suis personnellement, est assez simple : si  je trouve un pattern de code unique, c’est une occurrence, aucune refacto n’est alors nécessaire. Si je trouve un pattern de code répété deux fois, c’est une coïncidence, je ne fais pas forcément  une refacto ou seulement si je peux lier cette coïncidence directement avec une règle de l’exercice. Si je trouve un pattern de code répété plus de deux fois, c’est une récurrence et je m’empresse alors de faire une refacto pour limiter cette répétition.

Il peut sembler impossible de finir un exercice complexe dans ces conditions, c’est en partie vrai, en partie seulement. S’il faut bien se rappeler que lors d’un coding dojo, le but n’est absolument pas de finir l’exercice présenté, il est quand même souvent frustrant de s’arrêter à ce qui semble être le début de la solution après 1h30 de développement. Cependant, il ne faut pas oublier que la première partie du TDD impose la création d’un test ROUGE, qui ne passe donc pas. Or dans l’exemple des chiffres romains, une fois les tests pour ‘I’ à ‘XI’ passés puis refactorés selon les principes vu ci-dessus, il y a fort à parier que les tests pour ‘XI’ et ‘XII’ seront verts dès leurs création (donc inutiles selon les principes du TDD).

Les Défis de Programmation

Comme indiqué précédemment, les coding dojos sont de petits exercices qui s’effectuent en groupe, il existe plusieurs méthodologies de coding dojo pour cela :

• Le pair programming : les développeurs se mettent deux par deux (idéalement) derrière un PC et chaque équipe code en faisant des rotations au sein de l’équipe (l’assistant devient développeur et inversement). De plus, dans ce cas, on organisera à intervalle régulier des démonstrations où une ou plusieurs équipes viennent montrer leur code aux autres afin de présenter les différentes solutions apportées au même problème.
• Le mob : une seule personne code derrière le clavier. Cela peut être fait pour deux raisons, soit pour un kata d’apprentissage, auquel cas l’assemblée est là pour apprendre et le « driver » leur apprend quelque chose (un langage de programmation, un pattern, un algorithme, …) dans une session de live coding ; soit l’assemblée participe activement au développement en disant comment et quoi faire au « driver », généralement dans ce système on change de « démonstrateur » à intervalle régulier.
• Le randori : Peu fréquent mais intéressant, un duo de développeurs codent devant une assemblée qui participe activement au développement, on organise dans ces cas des rotations de pair, « l’assistant » passe derrière le clavier, quelqu’un de l’assemblée devient son assistant et le développeur qui était derrière le clavier passe dans l’assemblée.

On remarquera que pour le pair programming et le randori, il est question de rotation d’équipe, l’idée lors d’un coding dojo est d’effectuer cette rotation à chaque fois qu’un nouveau test est écrit et qu’il est rouge (étape 1 du TDD).

Et c’est tout ! maintenant vous connaissez tout ce qu’il y a à savoir pour organiser un coding dojo vous-même. On arrive donc à la question : « Pourquoi ferais-je ça ? »

Pourquoi faire des coding dojos ?

La première réponse peut sembler simple mais elle est essentielle : c’est fun. Prendre le temps de nous rappeler que le code c’est cool est essentiel. Ça nous donne envie d’apprendre toujours plus (dans un milieu qui évolue sans cesse, ce n’est pas un luxe), de s’améliorer, de maîtriser les bonnes pratiques et de les partager. Bref, rien que pour ça, les exercices de codes en groupe devraient être une norme. Mais ce qui fait que le coding dojo plus spécialement est intéressant c’est sa flexibilité d’apprentissage et les notions que l’on peut intégrer dans les exercices.

Le TDD premièrement, est vu comme une bonne pratique essentielle pour développer du logiciel de qualité. Bien pratiqué et appliqué à de « vrais » projets il permet d’accélérer le temps de développement et le temps de recettage, de réduire le risque de régression et d’améliorer la couverture de test de façon intelligente. Le problème c’est qu’il faut des mois pour appréhender cette technique correctement et être efficace et aussi que mettre en oeuvre du TDD sur du code existant est difficile pour les débutants ce qui est rarement compatible avec le cycle de vie classique d’un projet. C’est là où le coding dojo permet d’apprendre ces techniques à son rythme et sans risques.

Mais le vrai point fort des coding dojos est leurs flexibilités d’apprentissage, les exercices les plus simples peuvent être utilisés pour apprendre un nouveau langage, on peut ajouter des contraintes pour varier les disciplines. Besoin d’apprendre à mieux maîtriser un IDE pour accélérer le développement ? Interdisons la souris lors du prochain coding dojo, tous les participants ne peuvent utiliser que le clavier. Besoin de travailler sur un legacy lourd et d’apprendre à s’adapter à un nouveau code ? Les équipes vont échanger leurs PCs et leurs projets avec une autre équipe à intervalle régulier et devront s’adapter au nouveau code. Il existe également des coding dojos existant pour apprendre le refactoring d’un legacy (comme le Gilded Rose d’Emily Bache par exemple qui existe dans de nombreux langages).

Bref le coding dojo est un exercice qui apporte beaucoup de bonnes choses à une équipe de développement et dont je ne peux qu’encourager la pratique régulière.

Si vous souhaitez mettre en place vous-même un coding dojo dans votre équipe / entreprise / école, vous pouvez trouver des exemples d’exercices de coding dojo ici : http://codingdojo.org/dojo/, ou encore ici : http://codekata.com/ et il existe pleins d’autres sites qui proposent des exercices de coding dojo si vous manquez d’idées.