Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec J.P. Lambert, Jean-Pierre Bonjour.
Salut !
Ravie d'avoir nouveau sur le podcast.
On discutait à midi du TDD, de comment est-ce qu'on en arrivait à adopter le TDD, ou pas d'ailleurs.
Et tu me challenges là-dessus en disant, mais au fond, qu'est-ce qui amène les développeurs à se mettre au TDD ?
Et ben c'est une vraie question.
En tout cas, j'ai pas la réponse ultime, sinon le monde entier est code grand TDD, mais c'est pas le cas, force est de constater.
Ce qu'on constatait, c'est que ça partait quand même d'un moment donné, on constate que la maison brûle.
Ouais.
Comment tu vois les choses dans tes équipes et qu'elles recultent sur ça ?
Ce qui se passe, c'est sûr, c'est la maison brûle, on n'arrive pas à mettre en prod.
Dès qu'on me emprote, c'est une regression, on roll back, on récorrige, on irpares pour un tour et ça n'en finit pas.
Et voilà, pour plein de raisons qu'on imagine bien, on n'a pas de test, on est pareil gros, on écrit mal de code, on ne fait pas de TDD, etc.
Et donc en général, quand on est dans cette situation-là, oui, on fait quelque chose, on réagit quoi.
Non, et la maison brûle.
Voilà, donc on réagit, on fait quelque chose.
Potentiellement, on va quand même se mettre à faire plein de choses très bien, on se remet à travailler, d'être un peu plus carré,
à réfléchir à qu'est-ce qu'on fait, comment on le fait, à écrire des tests, automatiser les tests, ou simplement les faire,
parce que parfois on sait juste aucun test même pas manuel.
Donc on fait quand même plein de choses et les choses vont mieux.
Mais on ne se retrouve pas forcément à faire le TDD.
Voilà, on va se mettre à quand même faire des tests unitaires, on va le mettre dans definition of the delivery.
Il y a des tests unitaires, il y a un coverage même qui est assez élevé, parfois même ils disent 100% ou en tout cas 100%
sur la partie vraiment core, les règles métiers, business, etc.
Et on ne va pas faire le TDD, parce que finalement, même si on imagine le truc, on entend le nom, ça plane,
mais c'est chaud, c'est compliqué.
On se dit qu'il y aurait le reste des trucs, on les a fait, on voyait la valeur que ça nous apportait,
et puis finalement, maintenant la maison brûle plus.
Pourquoi est-ce qu'en plus on passerait au TDD alors qu'en fait c'est super exigeant,
et on efface des gens qui ne sont en fait pas persuadés de la valeur que ça va leur apporter,
et il n'y a aucun doute sur le fait que ça va être compliqué à adopter,
et le pain point principal n'est plus là, en tout cas c'est plus même celui qu'on avait avant,
il est plus là ou plus aussi fort.
Non, c'est clair. Et d'ailleurs, juste on va rembobiner à deux secondes quand tu dis les gens,
on le met dans le DOD, moi je faisais le constat que ça ressemble les plus souvent à un vœu pieu qu'à une réalité,
tu as sûrement plus d'expérience en ayant vu pas mal d'équipe.
Comment est-ce que tu dirais que oui c'est vraiment mis en œuvre, ou...
Non, j'ai quand même vu souvent vraiment, vraiment mis en œuvre,
elles font ce qui est écrit dans leur definition DOD,
en effettant il y a des fois où le DOD c'est un peu de la fume-mystery,
on le fait pas mais globalement, par du temps, les gens le font,
mais effectivement moi ça me fait un peu bondir parfois de les voir qui poussent très très très l'eau,
leur coverage, leur couverture de code.
En partant de zéro.
Et qui fassent toujours pas de t'aider, c'est-à-dire qu'ils ont cette exigence là qui est très forte,
ils envoient les mecs dans leur con quand ils passent une poulre request
et il n'y a pas 100% de coverage.
Non, sur cette partie-là, sur ce module-là, 100% de coverage.bar.
Et ils sont super stèques là-dessus.
Mais ils passent pas au TDD.
Tu vois ce genre de choses, le code, les couverts...
Ils les écrivent pas forcément après,
parfois ils écrivent en même temps,
en tout cas ils ne sont pas dans cette rigueur du TDD,
et parfois ils les écrivent même carrément après, les testues,
mais clairement ça ne passe pas à la phase du code review,
il n'y a pas de merges tant qu'ils n'ont pas atteint leur dot,
qui est 100% de coverage en tout cas sur ce module-là.
Mais pourtant, il n'y a toujours pas ce truc de se dire,
donc en plus si tu ne la remparts, ils vont te dire
ouais, il faudrait, ou moi j'y crois pas,
je ne suis pas persuadé de la valeur.
Il y a un point que tu soulèbes là qui est très intéressant,
c'est qu'on est encore dans un acte de foi avec le TDD.
Il y a encore des gens qui y croient ou qui n'y croient pas,
ce qui me paraît...
J'ai du mal parce qu'une fois que tu l'as vécu,
c'est plus une question de croyance,
on remarque peut-être que ceux qui ont une illumination,
c'est pareil pour eux, j'en sais rien,
donc peut-être qu'on reste effectivement dans le...
Mais en tout cas je constate qu'à ce langage-là,
j'y crois pas, ça marche pas, c'est pas pour nous.
Ouais, quand tu dis illumination, je pense que le terme est bien,
moi j'ai utilisé pendant longtemps, ce terme-là,
il y a illumination, c'est qu'il y a un moment,
en tant que développeur vis-à-vis du test,
il y a un moment où on a l'illumination,
on s'en compte que c'est la base du travail de développeur,
le test, et que c'est pas un truc à côté annexe
pour quelqu'un d'autre, ou qu'on fait si on a envie,
ou qu'on a le temps, et que c'est plutôt la base.
Déjà rien que ça, moi je dédivise en deux
un peu les catéories de développeurs, c'est celui qui a eu cette illumination
et ceux qui n'ont pas eu.
Et non, effectivement, je te dis, ils ont pas l'illumination
sur le TDD, après tu dis, les choses avancent quand même,
parce que quand on rembobine, peut-être dix ans en arrière,
c'était pas une évidence non plus,
qu'il fallait intégration continue, qu'il fallait faire le test unitaire.
Alors que là aujourd'hui c'est plutôt établi,
c'est clair et net que ça doit être là et que ça doit être fait.
Je pense que tu marques pas sur ça.
Ça fait vraiment passer ces mainstreams.
Par contre d'aller jusqu'au TDD,
c'est pas encore mainstream le TDD, clairement.
Je ne sais pas si ça le deviendra,
parce que la marche est haute.
Dans ce qu'on disait, c'est quelqu'un qui est nouveau au code,
qui est nouveau au développeur, et qu'on le formatte,
enfin on le formatte, c'est pas le bon terme, mais qu'on le forme directement.
Il n'a aucun problème avec ça, et c'est probablement très vrai.
Moi ce que je t'ai reproduit, c'est que à l'université,
on m'a appris d'abord la programmation fonctionnelle
et après l'impérative.
J'ai aucun problème à programmer un fonctionnel,
alors que ce qu'on voit dans le marché,
c'est que ceux qui ont fait plutôt dix ans d'impératives,
enjeux d'avaux, on sait, c'est compliqué de se dire
« maintenant je fais du fonctionnel, c'est un changement de mindset,
et finalement quand on incule le bon mindset au début,
c'est pas plus dur ».
Voir même, il y a une population qui m'a agréablement surpris,
c'est tous les gens qui sont en reconversion.
En fait je les vois se poser beaucoup de questions,
parce que sûrement je mets ça sur le compte de la maturité,
quelqu'un qui est en reconversion, qui a 30 ans, 40 ans.
Je pense un peu de vécu, un peu plus de recul, plus de maturité.
Et je constate que finalement qu'on soit débutant dans le métier,
en fait c'est orthogonal.
Voir même, en fait c'est même plus facile pour des personnes
qui sont en face d'apprentissage,
parce qu'il n'y a pas le billet de dire « maintenant j'ai 300, 3 ans, 5 ans,
je suis expert de ma techno, et qui sait ce mec qui va venir m'apprendre,
qui vient chambouler ma manière de réfléchir ».
Et il y a même, je trouve un frein, finalement,
en tant que t'as pas un peu ramé,
j'ai l'impression qu'il y a, soit t'en as vraiment chié,
il y a un moment donné tu te dis « c'est fini, ça c'est niet,
et je veux que mon quotidien soit un quotidien épanouissant ».
Et ça assez naturellement, tu vas tendre une oreille au discours TDD,
parce que ça t'amène à du feedback très rapide,
ça t'amène à une vraie maîtrise du code,
et tu es en totale maîtrise de ce que tu fais,
et ça c'est juste passionnant.
Ou alors tu as ceux qui arrivent à prendre le truc très tôt,
parce qu'ils ont un mentor, parce qu'ils sont sensibles à ça,
mais il faut reconnaître que c'est quand même très très loin,
tu me parlais d'être mainstream, je ne sais pas,
je pense que s'il y a 5% des gens qui codent en TDD,
ça me paraît déjà énorme, je pense que c'est même ça,
largement surévalué.
Je pense qu'on est à moins d'1%,
il y a encore peut-être un pour mille,
après dans ce que tu dis, il y a vraiment l'aspect
de ressortir les mêmes schémas de pensée,
ça suffit de faire un peu de dev,
qui seront peut-être les premiers à se plaindre
d'une gestion de projet, d'une gestion de management
à l'ancienne très...
voilà, il faut livrer, tu ne me fais pas de tests,
ça ne plaça pas de valeur, etc.
et en même temps ils vont reproduire exactement le même schéma,
c'est-à-dire qu'ils vont te dire la même chose,
non, ça m'apporte quoi, etc.
et, recrutiment, c'est des schémas assez différents,
il n'y a pas de sens à se dire,
enfin, on va plus vite qu'on fait de la qualité,
tout simplement, et ça, la plupart des gens
n'ont pas eu cette réalisation,
c'est toujours à se dire que la qualité,
alors que ce qu'il y a un coût, c'est la non qualité.
En fait, le truc, c'est que ça vient d'où,
c'est que la qualité a un coût,
parce qu'on a cette image du monde physique,
ou faire des choses de qualité, tu vois,
ta Ferrari qui va être faite à la main,
avec des matériaux nobles, va coûter plus cher,
pour moi, ça vient de l'industrie,
alors que nous, on fait quelque chose qui est dématérialisé.
On peut dématérialiser, est-ce que c'est ça la qualité ?
Moi, je te parle de qualité intrinsèque,
je te parle de faire quelque chose intrinsèquement
de bonne qualité, de bonne facture,
je suis préféré, mais c'est peut-être
une image luxueuse, on peut prendre les Allemands
qui ont la réputation d'une qualité intrinsèque forte,
si on fait la métaphore avec une bagnole,
mais il y a cette image quand même que si tu payes plus cher,
tu vas avoir quelque chose de meilleure qualité,
et que implicitement, le prix est corrélé à la qualité que tu payes,
et d'ailleurs parfois, le même produit positionné,
simplement plus cher.
Oui, donc c'est un biais naturel.
C'est un biais cognitif qu'on a.
Et du coup, c'est complètement à l'envers de cette pensée-là
que de dire, en fait, faire de la qualité
nous permettra d'aller plus vite et de gagner du temps.
Mais ça, c'est possible parce qu'on est sur quelque chose qui est immatériale,
et ça, je pense qu'il y a très très peu de gens qui l'ont compris.
Et d'ailleurs, Canback le dit bien,
j'ai une citation de lui, il faudrait que je l'arquise,
en faisant de la qualité, on va plus vite.
J'ai une phrase de Constantin sur le sujet aussi.
La qualité d'aujourd'hui, c'est notre productivité de demain.
Je l'aime beaucoup, celle-là.
Et je te propose que ce soit le mot de la fin.
Merci Jean-Pierre d'être venu aujourd'hui.
C'est le plaisir.
Si les auditeurs veulent en savoir plus, ils viennent.
Il peut valer sur mon blog, jp-lambere.me,
et puis il y a toujours, évidemment, Scrum Life,
qui continue à avoir toujours plus d'abonnés.
On a passé les 3500 l'air de rares.
Bravo.
Merci Jean-Pierre.
Quand t'as toi cher à rebonner, j'espère que tu as apprécié cet épisode.
Si c'est le cas, je t'invite à le manifester
en mettant 5 étoiles dans la plateforme de podcast de ton choix.
Spotify, Google Podcast, Apple Podcast, Soundcloud,
tel choix, tel choix, va où tu veux,
mais nous, s'il te plaît, une bonne étoile,
5 même en l'occurrence.
Avec un petit commentaire sympa, ça sera génial.
Et ça permettra de faire connaître le podcast.
Je te remercie et à demain.
Sous-titres réalisés par la communauté d'Amara.org