Bienvenue sur le podcast Artisan Developer, l'émission qui combine technique et agilité
pour partager la passion du code.
Aujourd'hui, je suis avec Guillaume Vincent, Guillaume bonjour.
Salut Benoît.
Je te propose aujourd'hui, puisque dans les préparations de cet épisode, on a échangé
sur quelque chose qu'on a fait sur une contrainte qu'on a eu tous les deux à un moment donné
dans un Cata ou dans un exercice, et j'ai trouvé intéressant, qui était de coder
sans TDD.
C'est-à-dire de manière très explicite de s'interdire de coder en TDD.
Moi, je l'ai fait dans le cadre de la formation que je suis en train d'écrire.
Là, aujourd'hui, on est le 7 août.
La première formation qui sera disponible dans la maison des compagnons.
Je voulais vraiment partir d'un bout de code legacy dont je me suis dit, essaye de voir
parce que dans la formation, je dis, finalement, si tu n'as pas besoin d'évolution, si ton
truc va être figé, est-ce que tu as réellement besoin de te préoccuper du design, c'est
pas sûr.
Et puis, la deuxième point, c'est de dire, encore faut-il être capable de le construire.
Et donc, je voulais voir quelle était la limite.
Je voulais tester quelle était la limite à partir de laquelle, sans des bonnes pratiques,
ça devenait vraiment intrinsèquement difficile de faire, ne serait-ce qu'un pas de plus.
Toi, est-ce que tu peux nous parler de ton expérience, justement, où tu t'étais
mis comme cette contrainte de codé sans TDD ?
Moi, c'était un peu la même idée.
Souvent, on explique que mettre des tests, ça prend trop de temps.
Et du coup, ça fait à peu près dix ans que je fais du développement piloté par les
tests.
Alors, je me suis dit, essayons 100.
Et sur un PET project, une application que j'ai faite le week-end, j'ai essayé de
partir sans test et de faire l'application comme ça.
Et très vite.
Et alors, du coup, qu'est-ce qui s'est passé ? D'abord, comment as-tu ressenti les choses ?
Alors, c'était très douloureux, en fait.
Étrangement, c'est très douloureux.
Je me suis vite aperçu que je ne savais plus coder 100 mètres de test.
Et je me suis aperçu très vite aussi qu'on faisait tout le temps des tests.
Mais les tests étaient transformés.
Je faisais plus de tests visuels.
Je faisais des requêtes sur mon API, dans mon terminal ou dans mon navigateur pour m'assurer
que les données étaient bien formatées.
Je faisais une série de tests qui étaient des tests manués.
Donc, en fait, on fait des tests.
Tout le monde fait des tests.
Personne ne code un truc sans le tester et puis l'envoi en production.
C'est juste que les tests sont manuels, très souvent.
Et donc, j'ai eu vraiment l'impression d'être au ralenti.
Quand je corrigeais quelque chose d'un côté, ça cassait de l'autre.
J'avais pas ma barre verte qui me donnait du feedback sur mon code.
Et donc, au début, ça allait plus vite.
Au début, très vite, on a des nouvelles fonctionnalités.
On a des boutons qui marchent, tout est rigolo.
Mais en fait, petit à petit, on va de moins en moins vite.
Moi, je ne prenais pas de plaisir à coder.
Cette notion que j'aime bien dans le test driven development,
c'est de voir de faire des petits pas, d'avancer par petits pas,
de prendre du plaisir avec des micro-victoires à chaque fois.
Et là, je les avais plus.
Et très vite, en fait, j'allais de moins en moins vite.
Quand tu dis très vite, si on essaie de quantifier ce très vite, c'est quoi ?
C'est une heure de travail, c'est 100 lits de code, c'est quoi ?
Ouais, c'est au bout de 2h, 2h, 3h.
Déjà, le code faisait des choses,
mais j'étais pas confiant sur le code que je produisais,
et puis j'étais pas à l'aise, et puis j'allais de moins en moins vite.
En quelques heures, en fait, je me suis retrouvé
à ne plus trop avancer aussi vite qu'au début,
et j'allais moins vite que quand je code de manière normale avec les tests.
Alors moi, mon expérience, je réouvre le fichier là.
Tu vois, le main, je me suis vraiment interdit de créer des classes.
J'essaye de voir juste un bon vieux main des familles.
Donc je suis parti sur le greeting kata qui me plaisait bien.
Et je me suis dit, voilà, il y a assez de matière pour faire un peu des choses.
En gros, ça fait 50 lignes, un peu moins de 50 lignes, le main.
Et je crois que là, moi, j'ai mis 3,5 heures à l'écrire, à peu près.
Et là, je crois que j'ai atteint ma limite, en fait.
C'est-à-dire que déjà, alors au début, ça passait vite,
tu vois, lire un fichier, parcer les lignes.
Je dois reconnaître que je n'ai pas ressenti de gêne dans les premiers temps.
Le début, effectivement, je travaillais à la console,
à regarder à chaque run.
Finalement, à chaque run, au lieu d'avoir une barre verte ou rouge
avec une information précise de ce qui va, ce qui ne va pas et de la progression,
c'était un mois de reconstruire cette info à partir d'un rapport de run.
Et finalement, au bout de 3,5 heures, quand j'ai fini,
ça commençait à devenir pénible.
C'est-à-dire que je commençais à m'y perdre,
parce que je crois que c'était au 7ème niveau d'indentation.
J'ai commencé à mon cerveau, tu vois, il avait du mal à raccrocher les wagons.
Et là, je me suis imaginé en train de dire, bon, ok,
donc c'est un cata dans lequel il faut faire,
dire, jouer aux anniversaires à une isle de gens dans ton all-email.
Là, je me suis dit, ok, maintenant, imagine que tu devais faire évoluer les exigences
avec une règle métier du genre, si j'ai le numéro de téléphone,
j'en vois plutôt un SMS et si j'ai l'image, j'en vois plutôt un email.
Et là, j'ai eu une espèce de blocage et je me suis dit, non, il n'y a pas moyen.
C'est-à-dire que là, en fait, je crois qu'avec ces 50 lignes,
j'ai atteint la limite de ce que je trouvais sain,
enfin, même pas sain, parce qu'à chaque fois, il fallait...
je me forçais, tu sais, à dire, non, non, mais là, tu préfères un extract method,
non, non, non, en line-to.
Mais là, c'est de la folie ce que tu es en train de faire là.
C'est pas grave, en line, tes variables, en line-to, vas-y, à fond.
Et ouais, je crois que pour moi, la limite, c'est 3,4, moins d'une heure de code,
et 50 lignes, et aller plus loin avec cette contrainte,
d'un coup, ça devenait...
c'était juste que ça faisait... non, quoi, c'était... non.
Le seul mot qui me venait en tête, c'était non.
Ça faisait plus de sens, tu vois.
C'était... je touchais la limite pour voir de l'exercice.
Moi, j'ai pas fait de cata sur ça, j'avais juste fait une application,
un peu de project, mais très vite, en fait, j'ai rajouté les tests.
Moi, j'ai pas attendu.
Au bout de trois heures, je me suis dit, voilà, tu vas moins vite que quand tu mets des tests,
donc arrête tes bêtises, mettez tes tests et...
Et avançons, quoi.
Et avançons, parce qu'en plus, c'était quelque chose que je savais que j'allais jeter,
donc je me suis dit, bon, si tu le jettes, pourquoi mettre tes tests ?
Souvent, c'est quelque chose qu'on entend aussi.
Ouais, bien sûr, bien sûr, ouais, ouais.
Et souvent, les choses qu'on veut jeter restent,
mais j'allais moins vite au bout de trois heures, quand je mettais les tests, donc voilà.
C'est le temps que je me suis dit.
Le R.O.I., moi, je dis toujours que...
On me demande toujours cette question, c'est quoi le retour ?
C'est à partir de combien de temps que tu as du retour en s'assurant l'investissement,
ça avec du TDD.
Et moi, je dis dès la première heure,
ou dès la première journée, tu vois, parce que les gens en général s'attendent à avoir des durées en mois,
quoi, non, dès la première journée, pour moi, il y a du retour sur l'investissement,
et finalement, ce que tu dis et l'expérience que j'ai faite,
conforte complètement ce point de vue-là.
Alors après, c'est pour des développeurs qui font du TDD depuis quelques années,
parce que changer de paradigme et de faire sans TDD, en fait,
ou de se mettre au TDD quand on n'en fait pas,
c'est, à mon avis, c'est à mon avis aussi douloureux qu'à abandonner le TDD.
En fait, changer vraiment de sa façon de faire, c'est quelque chose,
sortir de sa zone de confort, c'est quelque chose qui est pas...
Complètement d'accord avec toi.
Complètement d'accord avec toi, et c'est aussi tout le sens de ce que j'amène
et de leur dire, il faut être conscient que ça coûte moins cher,
mais à condition d'avoir la compétence, et qu'il va falloir l'acquirer à cette compétence.
Et que ça, par contre, effectivement,
se l'approprier pendant qu'on développe, là, à ce moment-là, oui, on avance moins vite.
Et comme quand on s'approprie n'importe quelle compétence,
c'est pas gratuit, l'acquisition de savoir faire.
Ça, ça prend.
Après, toi, je sais que tu es spécialiste du legacy,
donc je me pose une question, tu vois, j'ai ce morceau de code,
j'aimerais le refactoriser, justement, le but du jeu, c'était de créer un bout de code à freu
pour pouvoir jouer à le refactoriser.
Je me pose la question, j'ai envie de le faire avec et sans TDD,
avec cette croyance, mais que tu vas pouvoir, je te demande de challenger,
que finalement, si je ne fais que du refactoring avec, notamment, les outils intégrés d'InteligY,
j'ai peu de chance de casser ce que je suis en train de faire.
En fait, je me pose vraiment la question, est-ce que ça peut être une espèce de marche intermédiaire
vers le TDD que de commencer par faire du refacto de base de l'extract méthode,
de l'extract classe, tu vois, des petites choses comme ça, qu'est-ce que tu en penses ?
Si tu utilises un vrai IDE, oui, si tu utilises un éditeur de texte,
où il n'y a pas d'extract méthode, ça devient difficile d'être confiant dans sa modification,
ou alors on va se mettre à la fin de la test ?
D'accord, il faut être pougioir, d'accord, OK.
Mais du coup, oui, oui, c'est...
En fait, moi, je mets en place des tests souvent dans du code legacy,
parce que mon objectif, c'est de supprimer du code.
Mon objectif est d'atteindre la perfection,
et comme l'a dit Saint-Exupéry, il est atteint quand il n'y a plus rien à supprimer.
Mais quand on modifie du code, quand on transforme ce code-là,
quand on change des abstractions, quand on fait évoluer le code,
il faut qu'on ait du feedback sur est-ce qu'on a cassé quelque chose,
ou est-ce qu'on n'a rien cassé.
Mais moi, j'ai envie de rentrer le soir...
Le 3e truc que tu fais, c'est que tu commences par mettre en place le filet de protection, avec les...
Exactement.
Pour pouvoir rentrer chez moi le soir,
il me dit que je n'ai rien cassé, ou si j'ai cassé quelque chose,
j'ai mis en place tout ce qui était dans mes compétences
pour me permettre de modifier mon code de manière sereine.
Et c'est vachement important, parce que souvent, les gens ne modifient pas le code,
pas parce qu'ils ne savent pas faire.
Il y en a beaucoup qui savent les principes de base du clean code,
ou qui aimeraient bien introduire un design paterne particulier dans leur code.
Mais pourquoi toucher à du code qui fonctionne ?
On ne sait pas trop comment ça marche.
Si la dernière fois qu'on a touché ce code-là, on a tout fait péter.
Donc il y a une peur qui s'installe, et on améliore plus.
On vient rajouter juste le petit if au milieu de 50 if pour rajouter cette condition.
Parce que ça, c'est ce qui fera le moins de dégâts.
Et c'est là où moi, j'introduis du détest,
c'est que j'ai envie de pouvoir rentrer le soir et je transforme tdd,
je ne sais pas qui a dit ça, mais j'aime bien la citation, on transforme la peur en ennuis.
Ça devient presque ennuyeux de développer un tdd, parce que ça marche en fait.
Écoute, je te propose que ce soit le mot de la fin.
Les auditeurs qui ont envie d'en savoir plus,
ils peuvent venir ou Guillaume pour voir un peu ce que tu fais et comment tu connais.
Sur mon GitHub, github.com, Guillaume Vincent.
Super, merci d'être venu aujourd'hui.
Merci à toi de m'avoir invité.
Qu'en t'as toi, chère auditeur, j'espère que tout ça t'a donné envie de rejoindre la communauté des artisans développeurs.
Je t'invite à nous rejoindre sur artisandepveloppeurs.fr et je te dis à demain.