Dites, on est d'accord que le TDD, c'est pas du testing ?
Je discute hier avec Michael, on discutait de ce qui est amené au TDD.
On se posait la question, qu'est-ce qui fait qu'à un moment donné,
un développeur plonge dedans ?
Je crois que ça démarre souvent avec des galères.
Pour arriver à adopter le TDD,
soit tu as la chance de tomber dedans,
tu arrives dans une équipe et tu n'as pas le choix, tu le fais.
Soit si c'est un cheminement personnel,
il faut que tu en aies pas mal bavé quand même.
Tu vois ces moments où tu as des régressions en cascade,
tu te vendes le design, tu essaies de comprendre une classe,
et tu te perds dans les limbes des dépendances,
la conception est incompréhensible.
T'essayes de bouger un truc, ça prend des plombes,
tu as l'impression d'avoir des fils, des élastiques accrochées partout
qui te retiennent.
Au final, tu n'as plus rien touché.
Tu n'as plus touché parce que tu es déjà déprimé à l'avance.
Alors tu développes des techniques de ninja.
Comment faire évoluer le code sans toucher à ce qui existe ?
Je sais, c'est un truc assez tendance,
et c'est bien d'ailleurs, parce que ce sont des techniques de ninja
parfois très utiles, très intelligentes, mais moi ce qui me gêne,
c'est pas que tu cherches à ne pas toucher au code,
c'est plutôt un bon principe de design.
Ce qui me gêne, c'est la raison pour laquelle tu ne veux pas toucher au code.
La raison profonde, en fait, c'est que tu as peur.
Tu as la boule au ventre, rien d'imaginer les conséquences de cette idée géniale
qui vient de passer par la tête.
Tu sais que tu pourrais faire plein de trucs, mais d'un coup,
tu penses à tout ce qui va te tomber dessus et t'abandonnes.
Alors tu fais avec, tu te débrouilles tant bien que mal,
tu essaies de limiter la dette technique, tout en sachant que chaque jour,
tu en rajoutes un peu plus, chaque jour, tu fais grandir le spaghetti monster.
Beaucoup en reste à ce stade.
Beaucoup accepte ça comme une espèce de fatalité.
Non, il n'y a pas de fatalité.
Certains décident d'aller plus loin et puis ils se disent
« Ok, il faut faire autrement ».
Faut faire autrement et là, tu entends parler, tu tends l'oreille
et tu entends parler de ces mecs qui parlent d'un monde merveilleux,
le NoBugland.
Dans ce monde merveilleux, les bugs n'existent pas,
ou sont rarissimes,
les développeurs libèrent leur créativité,
ils codent avec plaisir.
Tu aurais presque l'impression que des pône et rose volent sur des arcs en ciel.
Ils se permettent les folies les plus excentriques,
il faut dire qu'ils n'ont peur de rien.
Comme on dit chez nous, on craigne des gânes.
Alors tu essayes et effectivement, tu écris des tests.
Vu de l'extérieur, tu écris des tests.
Et là aussi, pas mal de monde s'arrête là.
Mais en fait, t'es dédé.
C'est pas un truc pour faire des tests automatiques,
ça c'est qu'un effet secondaire,
utile du reste, ça fait intégralement partie du truc.
Mais c'est qu'un effet secondaire.
L'effet principal est que le TDD pilote le développement.
C'est un peu comme le poursalu, c'est marqué dessus.
Le TDD est une méthode de conception.
Une méthode qui s'oppose aux approches classiques,
dans le sens où elle se concentre sur ce qui est important.
Là tout de suite, maintenant.
Et non pas sur ce dont je pourrais avoir besoin dans 3 mois.
D'où ça vient ça ?
D'où ça vient ce besoin d'anticiper les choses ?
Mais ça vient de quand on construisait des maisons.
Ça vient de quand on faisait des choses physiques.
Parce que oui effectivement, on vous explique,
que faire une modification quand vous construisez une maison,
sur le plan ça coûte un coup de gomme.
Et une fois que la maison est livrée, il faut tout casser et recommencer.
Donc effectivement, on s'amuse pas à déplacer un mure-porter après coup.
Sauf que nous on travaille sur quoi ?
On travaille sur de l'immatériel, sur du virtuel.
Nous on peut déplacer des murs-porter pendant qu'il y a des gens dedans.
C'est pas un souci.
On a pas forcément besoin d'essayer de tout anticiper.
Tu sais, il y a toujours ce mec dans l'équipe qui te dit,
ah ouais mais ici un jour on a besoin de...
Eh bah tu sais quoi ?
On verra à ce moment-là.
Grâce au TDD, je m'épargne de gaspiller de l'énergie
à concevoir un truc dont je n'aurais peut-être jamais besoin.
Je n'ai pas à payer le prix tout de suite,
d'une surconception.
Le TDD me concentre sur le ici et maintenant.
Le TDD me donne confiance en l'avenir grâce au test
qui rassure et forme un filet de sécurité.
Le TDD est la voie pour coder en pleine conscience.
Paradoxalement, le fait de se concentrer sur le présent
est la meilleure manière de préparer l'avenir.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Pense à nous rejoindre si c'est pas déjà fait sur artisan-dev.com
et je te dis à demain.