Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Nicolas Verrino, Nicolas bonjour.
Bonjour Benoît.
Merci de venir. Aujourd'hui tu me proposais qu'on parle d'un sujet qui,
une fois n'est pas coutume de TDD et notamment pourquoi,
pourquoi est-ce que le TDD est si difficile à mettre en place, pourquoi il est mal compris
et tu commençais à me parler d'une vidéo sur the LIMP of Code fallacy.
Est-ce que tu peux élaborer là-dessus ? C'est quoi ton point de vue sur le sujet ?
Alors cette vidéo c'est d'un bonhomme qui s'appelle G-Po,
c'est le G-Po en Amérique, qui est assez charismétique
et qui explique en fait que TDD c'est mal compris
parce que au premier abord ça veut dire écrire plus de codes,
écrire des tests ça veut dire écrire plus de codes
et déjà que nous développeurs on n'a pas le temps d'écrire le code de production,
le code qui doit marcher, comment veux-tu qu'on ait le temps d'écrire des tests ?
C'est la première remarque qui fait.
Et ensuite il découpe un petit peu ce que c'est de développer un logiciel
et notamment que ce n'est pas qu'écrire du code.
Créer un logiciel ce n'est pas qu'écrire du code,
c'est aussi déjà savoir qu'il faut écrire,
il faut imaginer ce code, le concevoir,
il faut savoir les fonctionnalités qu'on veut créer,
il faut discuter avec les utilisateurs, comprendre ce qu'on attend du code
et du coup il en vient à expliquer que TDD ça demande d'écrire plus de codes
mais écrire du code ce n'est pas ce qui prend le plus de temps pour créer un logiciel,
ce qui prend le plus de temps c'est imaginer ce code-là
et TDD permet d'aller plus vite dans cette imagination
et d'apprendre, enfin d'un autre, de concevoir plus vite le logiciel
et d'être plus efficace sur cette tâche-là
qui finalement, elle prend une partie non négligeable du temps de développement
et c'est pour ça que TDD quand c'est une technique qui est maîtrisée
permet d'aller plus vite pour créer un logiciel et pas moins vite
donc certes on écrit plus de codes mais on écrit du meilleur code
et surtout on arrive à imaginer ce code-là plus facilement et plus rapide
et c'est ça qui prend le plus de temps
et toi tu d'accord avec cette assertion ?
moi je suis...
moi je t'avoue que je ne suis même pas d'accord sur ça
mais est-ce que tu trouves que tu écries plus de codes en faisant du TDD ?
alors ça dépend
avant le refactoring on écrit...
oui on écrit quand même plus de codes
alors à la fin le code produit est la plupart du temps moindre
donc à la fin il y a effectivement moins de lignes de codes qui ont été disons comitées
moins de codes réels qui ont été comitées
par contre si on regarde toutes les lignes qui sont produites puis défaite puis faite autrement
lors de la phase de refactoring
au global on écrit plus de codes
il y a plus de codes qui sont écrites
et après la plupart des lignes sont effacées, modifiées et refactorisées
donc effectivement à la fin on a moins de codes
mais si on regarde tout le processus on écrit plus de codes
et c'est une technique, un outil qui nous permet de concevoir et de manipuler ce code
comme on manipulerait de la pata modélée
oui j'aime bien ton analogie avec la pata modélée et ta manière de voir les choses me convient
et en tout cas étant en ligne avec ce que je pense
c'est à dire moi je suis convaincu qu'en je réfléchis aux codes que j'écrivais avant de passer au TDD
il y avait clairement plus de volumes au final
pour faire la même chose, des choses équivalentes
il y avait clairement plus de volumes, beaucoup plus de volumes
et donc du coup TDD, j'ai l'impression
c'est un standard un peu retenu par l'industrie
c'est qu'on écrit moins de codes au final
après tu as raison de dire qu'il y a ces phases intermédiaires de travail
où on pétrit notre code
et ça effectivement ça prend du temps
mais ça pour moi ça fait partie du processus, d'élaboration
donc je l'avais pas vu comme ça
il y avait une perspective nouvelle et intéressante
moi ce que je retiens surtout c'est que ça va plus vite
tu vois à un moment donné la mesure objective qui est quand même simple c'est
ça va plus vite
et quand je dis ça va plus vite c'est en intégrant tout
parce que moi j'ai le souvenir d'un gars qui m'avait dit ça
cette fonctionnalité pfff non on va pas faire des tests c'est bon
demi journée c'est réglé
effectivement il a mis une demi journée mais derrière il a mis 3 jours à débugger
donc je sais pas toi avant de passer TDD
tu passais combien de temps en débug ?
j'ai jamais vraiment mesuré mais je le vois
parce qu'il y a certaines parties où je suis obligé de passer en débug
pour tout ce qui est je vais regarder si mon interface allait bien
elle s'affiche correctement et ce genre de choses là
donc je peux très facilement passer 50% de mon temps à regarder
que mon code il crée le bon affichage
par contre quand je suis sur une fonctionnalité qui ne nécessite pas du débug
je suis typiquement dans une fonctionnalité qui est entièrement testable
ou en grande partie testable
là je gagne un temps fou sur le débug
surtout que ma chevelle de l'IOS c'est compilé
donc il y a forcément un temps de compilation et de run à chaque fois
il faut naviguer dans l'app pour aller voir ce qui se passe
il suffit que ce soit une fonctionnalité qui soit un peu cachée au fin fond de l'app
ça peut prendre vite du temps de débugger
parce que rien que pour arriver à la fonctionnalité on va prendre 15 secondes
et 15 secondes 50, 60 fois par jour
ça fait du temps et de l'énergie
alors quand t'aider on lance les tests
en moins de 2 secondes on a le feedback
et donc on arrive à y tirer beaucoup plus rapidement et à voir si on fait fausse route ou pas
donc ouais je dirais que un temps de débugage sans faire du tdd
ça occupe 50 voir 70% du temps de dev
et quand on fait du tdd ça s'est réduit à 5-10%
c'est clair moi j'ai le souvenir d'avant
je pense c'était un bon 70% de temps passé à chercher les problèmes
on peut même développer une véritable expertise avec le débugger
je sais que ça fait 8 ans que je fais du rails
en fait j'ai eu besoin
j'ai vraiment ressenti le besoin d'un débugger une fois
et c'était dans les 6 premiers mois de rails
parce qu'il y avait des trucs un peu magiques que je comprenais pas
notamment du rubien et je comprenais pas
là j'avais prouvé le besoin de pouvoir faire un break
voir quel était la call stack et quelle était la valeur de la variable
mais depuis ça m'est plus jamais arrivé
et ça m'arrive même assez régulièrement
je code toute la journée et j'ouvre le navigateur vraiment à la fin
pendant que l'intégration continue est en train de me dire
ok tout va toujours bien histoire de vérifier
quand même je lance le serveur en local histoire de vérifier que le truc que je viens de faire
globalement du point de vue de l'utilisateur se comporte de manière cohérente
parce que ça m'est déjà arrivé des blagues du genre
t'as oublié une bêtise qui fait que la future elle est juste pas accessible
tu vois mais je te pose la question à toi aussi
chère auditeur combien de temps est-ce que tu passes sur ton débugger
ça m'intéresse que tu nous le dises tu peux nous le mettre en commentaire
et réfléchis à qu'est ce qui changerait dans ta vie si tu passais pas ce temps à débugger
ça y est aussi un truc important c'est comment je prépare mon système pour tester les corner keys
donc comment je vais simuler une perte de connaissance internet
comment je vais simuler un utilisateur qui est plus valide et ce genre de choses là
à chaque fois je fais quoi je laisse du code commenter
que je décommente de temps en temps quand je vais tester les choses
et qu'est ce qui me garantit que j'ai pas pété quelque chose aussi
rien que tu écoutes là ça me donne la chair de poudre de partout là
laissez du code que j'active des actifs pour pouvoir tester
faut commencer à voir l'estomac qui se tord qui se noom
si tu oublies du code que tu passes en prod ça va donner quoi
tu la connais avec la perruvante c'est pas terrible
alors qu'avec t'es dédé justement on prépare le système qu'on a envie de le voir
et ça ne part pas en prod, ça ne peut pas partir en prod
car c'est un projet de test qui s'est paré
écoute Nico je te remercie je te propose que ce soit le mot de la fin
si on a envie d'en savoir plus sur tes activités et sur ce que tu publie on peut venir où
alors on peut aller sur refacto.fr
ou alors on peut me suivre sur Twitter
ou sur LinkedIn
je te remercie d'être venu Nico
je t'en prie
quant à toi cher auditeur si tu n'es pas encore membre de la communauté
viens vite nous rejoindre sur artisandeveloper.fr
et si c'est le cas que tu es déjà membre
tu sais quoi tu peux partager ça et inviter
deux autres personnes à venir rejoindre la communauté avec toi
je te remercie je te dis à demain