Depuis que j'ai commencé à accompagner les clients pour les faire monter en compétence sur le TDD (Test Driven Development), je me posais ces deux questions : Pourquoi a-t-on du mal à adopter le TDD ? Et lorsque l'on l'adopte pourquoi a-t-on du mal à l'appliquer au quotidien ? Je me suis rendu compte au fil des missions de coaching que commencer le TDD est semblable au démarrage d'un régime minceur. C'est dur de se fixer des restrictions ou limites au quotidien et c'est difficile de les assumer. Tout au long de cet article nous allons voir ensemble comment transposer les règles d'or d'un régime réussi au TDD pour y persévérer. Mais avant de commencer voyons d'abord la définition du TDD.

TDD : Test Driven Development

« Test-Driven Development » est une méthode qui prône une nouvelle gymnastique de l’esprit et une nouvelle discipline : écrire le test avant le code de production. L'idée est donc de se fixer un objectif à atteindre en écrivant un test. Ce dernier permet de savoir quand s’arrêter de développer le comportement attendu. Dans un premier temps, le test sera rouge à l’exécution puisque le comportement du code correspondant n'existe pas encore. Attention la phase rouge ne veut pas dire que le code ne compile pas. On doit donc avoir créé manuellement ou généré via l’IDE la méthode à appeler. La deuxième phase correspond à écrire le minimum de code pour que le test passe au vert. Et enfin la factorisation du code permet de l'améliorer et d’obtenir une meilleure lisibilité et maintenabilité en troisième phase. On parle alors du cycle "Red Green Refactor" comme présenté dans l'image ci-dessous.
Souvent les développeurs se plaignent que l'application de la méthode est difficile. Effectivement, c'est dur de changer du jour au lendemain sa façon de travailler. Pendant des années on a vécu avec l'idée qu'un développeur produit l'application et le QA (Quality Analyst) la teste. Avec l'automatisation des tests, les habitudes ont un peu changé et les développeurs ont commencé à écrire aussi le code des tests. Le TDD pousse la réflexion plus loin en incitant à écrire le test avant même le code. J’entends souvent des réflexions de ce type : Le temps d'apprendre le TDD, il y aura une autre méthode qui sortira et on sera dans un cercle sans fin. Et pourquoi donc perdre son temps à toujours apprendre ? Et puis il faut prendre le temps pour concevoir la solution avant de commencer à coder. Et quel serait mon premier test ? ... Bref, après tout, on vit bien avec la méthode actuelle. Je crois toujours en l'expression "si on veut, on peut", il suffit d'être motivé et surtout de bien planifier sa progression pour réussir. Il ne faut pas être trop gourmand et vouloir apprendre tout à la fois. Il faut trouver le bon rythme justement, le vôtre. Le but est de ne pas se priver des autres choses et donc éviter de se décourager ... Ça ne vous rappelle rien tout ça ? Moi ça me rappelle les conseils pour réussir un régime minceur. Avez-vous déjà essayé de suivre un régime ? Avez-vous réussi à tenir jusqu'au bout ou avez-vous craqué à la première sortie avec les copains/copines ? Mais comment faire pour réussir un régime ?

Règles d’or d’un régime réussi

D’après les experts en nutrition, les règles d’or d’un régime réussi peuvent se résumer en cinq points. Voyons comment les transposer au TDD. Et pour mieux comprendre la transposition, utilisons un kata simple de fusion de périodes, tiré de l’univers de l’énergie. Imaginons un ensemble de périodes. Chaque période a un poids. Et on veut fusionner les périodes successives qui ont un poids à zéro. Prenons ces périodes comme exemple :
01/01 -> 31/01, 0
01/02 -> 28/02, 0
01/03 -> 31/03, 10
En appliquant l'algorithme nous arrivons à ce résultat :
01/01 -> 28/02, 0
01/03 -> 31/03, 10 Ça parait simple et pourtant certains passeront au moins quelques minutes à chercher une solution pour le problème en intégralité. Voyons comment, en appliquant les règles d'or du régime, s'en sortir en minimisant le temps de conception et en appliquant le TDD en souplesse.

Viser des petits objectifs

Les experts conseillent de ne pas se fixer un objectif du type perdre 10kg en un mois car ce n'est pas raisonnable même si certains y arrivent. Le risque réside dans les carences et surtout la déception de ne pas atteindre l'objectif. Les petits objectifs sont plus facilement atteignables et augmentent le niveau de satisfaction. Donc fixer de petits objectifs aide à garder le rythme et rester motivé. En TDD, l’idée est de faire des baby steps. Ce sont des petites étapes pour atteindre la solution complète. Avant de commencer à développer la tête dans le guidon, il vaut mieux prendre le temps de regarder quelques exemples liés à notre problème (du plus simple au plus complexe). Ça peut paraître trop simpliste pour certains mais ça aide à construire le code petit à petit. Pour notre kata, voici des exemples de complexité croissante :

• Collection vide => collection vide
• Collection avec une période => même collection
• Collection avec deux périodes à zéro => collection avec une seule période à zéro
• Collection avec deux périodes à poids différents => même collection
• Collection avec trois périodes (2 poids à zéro et un poids différent) => collection de deux périodes (une à zéro et une non)
• …

Le test (du premier exemple) permet de définir la signature de notre méthode. Ainsi le déroulement de la solution devient plus fluide.

Réduire les portions

L'idée est de réduire la portion des repas. Donc, si on aime manger dans une assiette bien garnie ou si on fait partie de ceux qui n'arrivent pas à concevoir une assiette non remplie, il vaut mieux changer la taille de l'assiette et utiliser une plus petite comme celle de dessert par exemple. Ainsi mentalement, on est rassuré d'avoir une assiette bien remplie bien que réellement la portion est moindre. Il ne faut pas s’inquiéter, on n'aura pas faim pour autant. En développement, un problème est toujours divisible avec un peu d'imagination. Pour le kata, on peut imaginer une première version qui ne prend pas en compte les trous entre les périodes (on considère que toutes les périodes sont contiguës) et une deuxième version qui gère les trous. Les tests existants pour les périodes sans trous assurent ainsi une non régression. On peut donc avancer sereinement.

 Compter les calories

Il parait que 2500 kcal suffisent comme apport journalier donc pourquoi manger plus. Calculer les calories incite à manger sainement et plus équilibré. Par exemple, un burger ne va pas suffire à rassasier parfois et pourtant c'est la moitié d’un apport journalier. On parle souvent d'un plat calorique, mais on oublie qu'un code peut l'être aussi. Je conseille toujours de compter régulièrement la complexité des méthodes pour veiller à garder un code plus diététique. On peut lancer l'analyseur après le lancement des tests. Ainsi on veille à ce que la complexité ne s'élève pas. Si on remarque que la complexité s'est accrue d'un coup, il ne faut pas hésiter pas à extraire du code dans une méthode ou peut-être même en une classe s'il s'agit d'une autre responsabilité. Il ne faut pas hésiter pas à le faire bien sûr à l'étape du refactoring du TDD (Cycle "Red Green Refactor"). Calculer régulièrement la complexité assure que le code reste le plus simple possible. Il ne faut pas se prendre la tête à vouloir en faire des tonnes, « KISS » (keep it simple, stupid). Généralement, on veut écrire du code "clean" dès le premier commit, on veut que ça soit bien optimisé, bien "smart" comme on dit. Mais, on va passer beaucoup de temps à réfléchir et concevoir et entre-temps rien n'est produit. Il vaut mieux produire une première version minimaliste qui ne soit pas forcement optimale mais qui soit simple et qui répond au besoin et ensuite l'améliorer si le contexte évolue.

Manger ne réglera pas vos problèmes émotionnels

Quand on est adepte du chocolat dans les moments difficiles car ça procure une sensation de zénitude et qu’on est plus détendu après, il faut se méfier. Avec ces petits écarts, à la fin c'est la graisse qui s'accumule. Sur les projets, on a hâte d’apprendre le TDD et de le pratiquer mais on a toujours tendance à partir la tête dans le guidon pour finir les tâches et on oublie l’apprentissage. C’est pourquoi, il vaut mieux oublier la gourmandise et adapter l’apprentissage à son rythme. Car si on force les choses, ça ne sera que souffrances et on va vite lâcher l'affaire. En plus, on doit prendre du temps pour faire des rétrospectives et noter ce qu’on ressent afin de déterminer les actions pour une amélioration continue.

Faire de l’exercice

Les experts en nutrition conseillent souvent de faire au moins une demi-heure de marche par jour. C'est mieux de faire des exercices physiques trois fois par semaine pour accélérer la réussite du régime. En effet, le corps va éliminer la graisse plus rapidement et ça va faire travailler vos muscles. Les katas (des exercices pour pratiquer) ou les coding dojo sont nombreux sur internet et comme tout nouvel apprentissage, il faut de l'exercice donc il ne faut pas hésiter à en faire régulièrement. On peut même inventer son propre kata et en faire profiter la communauté 😉

 Les freins d'un bon régime

Les règles d’or sont simples à appliquer. Bon j'avoue "compter les calories" est difficile sans connaitre les données de référence. Mais on peut les apprendre au fur et à mesure. En appliquant ces règles, on a plus de chance de bien réussir le régime mais on oublie souvent que même avec la plus grande volonté, on vit dans un environnement parfois très tentant. Cet environnement complexifie en effet la donne. Car on va voir que certains freins incitent à baisser les bras et arrêter de poursuivre son régime.

Maigrir dans une famille sans complexe

Certains parents essayent de dissuader leurs enfants de suivre un régime. Ils considèrent que personne n'en a souffert dans la famille et puis c’est en opposition avec la génétique transmise. Sauf qu'ils oublient par bienveillance les difficultés liées au surpoids.
Dans une équipe, c'est pareil, quand on est le seul à faire ou à vouloir faire du TDD, il faut s'accrocher car on est dans le sens contraire du courant et la difficulté à avancer s’accroît. On est tellement bien dans sa zone de confort ; pourquoi aller chercher de nouvelles méthodes ? Et puis, on a bien géré les difficultés à chaque fois et à la prochaine on n'aura pas l'effet surprise puisqu'on sait comment les traiter.

Quand manger c’est aimer

J’imagine que c’est déjà arrivé à certains le fait d'être invité chez un parent et au moment de rentrer, il prépare la gamelle pour le lendemain ou le soir même. C'est gentil de sa part, sauf qu’on a déjà prévu des sorties avec des amis et donc la gamelle finira malheureusement à la poubelle. Eh oui quand on aime partager et faciliter la vie des proches, on pense à anticiper leur futur sans forcément les concerter. Ça part d'une bonne intention à la base par contre c’est dommage d'avoir perdu du temps à préparer alors qu'on ne va pas en bénéficier. C'est bien ce qui arrive sur les projets. On imagine le futur et l'évolution de l'application alors qu'à l'instant t, on n'en a pas besoin. Ce n'est pas la peine de créer une application qui prend en compte des milliers d'utilisateurs alors que réellement on a juste une dizaine, ou alors créer un code générique alors qu'on a besoin juste de gérer deux types d'objets. Peut-être que dans le futur on aura besoin de ces évolutions. Au moment opportun, la modification sera la bienvenue et on prendra une meilleure décision car le contexte aura changé. Mais c'est possible aussi que l'évolution n'arrive jamais et donc on aura perdu du temps pour rien. Ça serait dommage !

On confond aliments et médicaments

Quand manger répond à un besoin psychologique et non physiologique, on stocke directement toutes les graisses. Un bon carré de chocolat soulagera nos peines de la journée. Ou alors la sensation d'avoir faim survient après une réunion stressante alors qu'on a bien mangé le midi. Les experts recommandent dans ce cas de manger des fruits au lieu de biscuits ou d'autres cochonneries. Lorsqu'on apprend la pratique du TDD, on a tendance à faire beaucoup d'effort et à avoir de la frustration, il faut avouer qu'apprendre seul est parfois pénible et fait chuter le moral. Dans ce cas, il vaut mieux participer aux meetups pour pratiquer en groupe. Ça aide à se rendre compte qu’on n’est pas seul et la motivation augmente. Les meetups ont un effet de thérapie de groupe. En effet, on va partager les frustrations, les craintes et les problématiques et on va recevoir des réponses des pairs sous forme de retours d’expérience ou de conseils. Ça donnera de la motivation pour continuer à avancer.

On ne réussit pas à s’affirmer

La colère pèse sur l'organisme et le corps a du mal à la digérer. C'est impossible de perdre du poids tant qu'on n'ose pas être soi-même et se faire entendre. On essaye d’apprendre souvent à dire non quand on sait que ça ne tient pas le coup.
On connait tous cette réplique "Allez, c'est juste un if à rajouter !" quand le métier vient demander de faire en speed (ou en soum-soum comme on dit :p) une évolution estimant qu'elle est simple. On arrive parfois sur des projets qui existent depuis un certain temps. Les grosses évolutions y sont rares et la majorité des user-stories ou taches concernent une petite évolution qui ne prend pas beaucoup de temps.
Ces petites évolutions sont la meilleure opportunité pour pratiquer le TDD. Donc il ne faut pas oublier de s’affirmer.

La peur de ne plus se retrouver

Même si on n'aime pas son corps, on a construit notre identité avec lui. Devenir mince c'est devenir peut-être une nouvelle personne, basculer dans l'inconnu. On se pose rapidement ces questions quand on commence un régime « Est-ce que l'entourage va m'accepter avec mon nouveau corps ? », « Est-ce que je vais rester la même personne après le régime ? »
En appliquant le TDD, on va essayer de convertir d'autres collègues. Mais il faut se poser la question « Est-ce que je ne vais pas les embêter avec mes convictions autour du TDD ? ». A ce moment, il va falloir faire attention à son comportement avec les amis et les collègues développeurs. Il faut se rappeler de son point de vue d'avant la pratique et donc être compréhensif envers les personnes réfractaires, et surtout être patient avec les personnes qui veulent apprendre et qui vont chercher à nous solliciter souvent. Il ne faut pas oublier non plus d’avoir de l'empathie envers celles qui se plaignent tout au long de l'apprentissage car le chemin est long et l’apprentissage est dur.

Conclusion :

Dans cet article, j'ai pris l'exemple du régime minceur mais c'est applicable aussi à tout régime alimentaire. Si vous avez passé le cap pour devenir végétarien ou vegan, ou même si vous avez repris le sport, la difficulté est la même. Posez-vous la question « quelle est la motivation qui m’a poussé à garder le rythme et ne pas abandonner ? ». Transposez-la dans votre code et vous verrez la magie opérer. Voyons donc, ce n'est pas vraiment magique, ce n'est que de la volonté. 😉
Je compare souvent le code au corps. Plus on prend soin de notre corps mieux on vit et plus on prend soin de notre code mieux il vit.
Vous savez tout, à présent, sur comment réussir votre régime TDD. Il ne vous reste plus qu'à vous lancer. N'hésitez pas à me contacter si vous avez besoin d'accompagnement ou de plus de conseils.
Vous trouverez le kata sur mon github https://github.com/iAmDorra/ContiguousPeriod  

Ah ! Avant d’oublier, j’ai réalisé moi-même les petits personnages des photos de cet article avec ma tablette. J’espère que vous aimez 😊
See you 😉