Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Raleid Souff, Raleid est ce que tu peux te présenter s'il te
plaît en quelques mots pour ceux qui ne te connaitrait pas.
Oui, en quelques mots je suis présente comme Global Trotter Developer, parce qu'en fait
j'ai fait 4 pays jusqu'à maintenant en fait en tant que Developer, j'aime bien bouger.
Donc j'ai bossé en Tunisie, en France, au Canada et aujourd'hui je suis frontalier
et je travaille en Suisse.
Donc voilà, je suis passionné par le craft, j'ai découvert ça il y a 2000-2013 à peu
près et finalement ça va beaucoup plus, l'approche elle va beaucoup plus du fait
en fait on fait de la qualité, on n'est pas forcément focus sur les outils, même si
les outils c'est très important de les maîtriser mais on les focus plus sur notre mode de fonctionnement,
comment on appréhende les choses, comment en fait on s'améliore sur notre artisanat
parce que finalement en fait coder c'est finalement de l'artisanat.
Yes, et aujourd'hui alors de quoi est-ce que tu es envie qu'on parle ?
Alors ce que j'aimerais parler c'était c'est plus en fait du pragmatisme et de la façon
en fait d'aborder les outils et quand je parle d'outils je parle surtout des méthodes
que ce soit DDD, que ce soit DDD, que ce soit BDD qui sont aujourd'hui, je le précise aujourd'hui
les meilleurs outils aujourd'hui pour faire du craft, ça n'empêche pas que demain il peut y avoir
d'autres méthodes qui peuvent suppénir nos besoins.
Qui peuvent émerger, en préparation de cet épisode tu me disais que tu voulais réagir un petit peu
à l'espèce de clash qui avait lieu, je pense que tu fais référence au clash avec Kevin ?
Oui un peu.
Donc cher auditeur si tu ne sais pas de quoi on parle je t'invite à venir suivre sur artisandeveloper.fr
j'ai fait un post de recap qui explique un peu cette espèce de drama qui a eu lieu entre Kevin et moi
et d'ailleurs c'est pas fini puisque voilà il y a encore cet épisode qui vient nourrir le drama
on va continuer dans lequel Kevin a une thèse sur le fait que ce ne soit pas une bonne idée de mettre en oeuvre
des techniques de craft pour les startups et les stages et autant te dire qu'on n'est pas d'accord
et c'est un peu le coeur de l'objet.
Alors moi j'ai fait pas mal de startups juste pour comme ça en fait je mets le contexte que je ne parle pas
en fait de quelque chose que je ne connais pas.
Les startups c'est très particulier parce que tu dois délivrer de la valeur très vite
sauf qu'en fait le vrai problème que moi je remarque c'est que quand les personnes ils sont sous stress
en général ils vont essayer de laisser tomber en fait leur approche qui en fait quand ils sont en fait
en mode normal c'est-à-dire en fait s'ils font du DDD s'ils font du BDD s'ils font du DDD c'est pourquoi
parce qu'en fait le cerveau il est comme ça dans le sens où quand quelqu'un il est sous stress il va
pas faire du sport il va essayer de rester dans son point et essayer de manger il va commencer à accumuler
des mauvaises habitudes et sur ça je vais me baser en fait sur un talk d'une amie que je connais très très bien
qui est Dora Bartaguis elle a fait un talk en fait en expliquant en faisant la similarité entre faire du
TDD et un régime alimentaire.
Donc en fait de ce point là moi ce que je pense c'est que ça m'intéresse vachement c'est quoi ça t'a
fait ? Donc en fait ce qui se passe ça veut dire que la personne quand elle est à l'aise forcément
va faire son régime donc elle va suivre en fait un régime très esthrique en fait par rapport aux
aliments qu'elle va manger mais dès qu'elle va avoir en fait d'autres facteurs extérieurs qui vont
générer un certain stress elle va commencer à perdre du contrôle sur certains aspects de sa vie.
Ok donc ce que tu veux dire si je récapitule c'est que tu as crédit plutôt l'idée selon laquelle
en startup ce soit un contexte difficile stressant du coup moins propice à mettre en oeuvre des
pratiques du type TDD c'est ça ? Inconsiennellement donc de façon inconsciente.
Alors là tu vois ça devient intéressant tout de suite on rentre dans le coeur dans le truc.
L'analogée avec le régime je la prends bien volontiers parce que des régimes j'en ai fait plein
et là pour une fois c'est en train de marcher mais qu'est ce qui a changé ? C'est que je suis
plus en train de faire un régime je suis en train de changer ma manière de m'alimenter et pour
moi le TDD si on continue la métaphore c'est exactement pareil. Est ce que tu continues
un régime qui demande un effort ou est ce qu'en fait tu es en train de changer ta manière de
côté parce que moi sous stress je suis plus efficace avec du TDD et à chaque fois je ne sais pas
toi mais moi à chaque fois que j'essaye de prendre un raccourci en me disant allez ça ça passe
même sur des trucs en général les trucs où je me dis ça ça passe c'est des trucs super bateaux.
Tu peux être sûr 8 fois sur 10 c'est pas 9 fois sur 10 que je fais une merde derrière je fais une
cagade et du coup à chaque fois l'espèce les 1 minute 30 que je croyais avoir économisé j'en ai
perdu 10 derrière mais c'est quasiment systématique tu vois donc le constat empirique que je fais c'est
que je suis plus efficace sous stress avec ça. Qu'est ce que tu en penses toi ? Alors c'est là
où je vais en fait ça dépend de ton niveau de maturité sur les méthodes et ça c'est très important
ce sujet là en fait parce que je voulais l'aborder aussi et là c'est bien en fait parce que t'as
mis le point là où il y avait en fait le problème. Quand j'ai commencé à expliquer en fait que le
fait que c'était sous stress il y a une condition très très importante c'est qu'en fait qui va
retomber dans ses travers c'est celui qui finalement n'a pas maîtrisé la méthode TDD mais pas disant
en fait n'est pas au pic de performance par rapport à TDD et pourquoi ça c'est parce que tout
simplement cette personne là ou la personne en question elle a pas fait en sorte que TDD ça
devienne une de ses habitudes et là je rebondis c'est que c'est que y'a ce qu'on appelle les mauvaises
habitudes et si TDD c'est pas une habitude c'est-à-dire en fait c'est pas quelque chose qu'on fait à
chaque fois en fait qu'on attaque un projet et que finalement c'est fait de façon inconsciente on
n'a pas injecté dans nos têtes parce qu'on n'a pas fait assez souvent c'est parce qu'en fait c'est
un mode de comme tu viens de le dire c'est un mode en fait de codage ne devrait pas être traité
comme quelque chose de plus ou quelque chose de nice to have et aujourd'hui c'est ça le souci c'est
que les gens par exemple qui sont un start-up qui vont tout de suite en fait discarder TDD dans la
plupart des cas si ce n'est tous les cas c'est des personnes qui vont être qui en fait soit ils ont
appris TDD un peu tard et finalement ils montent de maîtrises un peu donc en fait ils sont pas
ils sont pas à 100% sur TDD soit soit finalement en fait ils veulent faire du TDD ils n'en font pas
et finalement TDD pour eux c'est dans leur tête c'est quelque chose de pas important c'est que
finalement ce qui les intéresse c'est juste de faire le produit de faire sortir le produit
donc il y a deux façons soit assez inconsciemment soit c'est consciemment qu'ils le font en disant
ok je vais cumuler de la dette entregumé et après je la récupère plus tard ce qui est complètement
faux parce que à mon sens les concessions ils doivent pas se faire là et c'est là où c'est un
pattern que moi j'ai vu assez souvent en fait quand je faisais du coaching TDD les gens ils font
toujours en fait les mauvaises concessions quand ils sont sous presse et la première mauvaise
condition qu'ils font on va enlever les tests alors qu'en fait il y a tellement de trop chose sur
lequel tu peux optimiser bien sûr on peut gagner on peut gagner et encore une fois même
je j'ai du mal à adhérer cette vidéo allez si je me mets dans la position de quelqu'un pour
qui faire ça demande un surcoût d'énergie puisque moi c'est pas le cas je gagne de l'énergie donc
j'ai du mal même à faire de concessions tout court sur les tests puisque tu m'enlèves un truc qui
m'accélère comme tu me disais conduit plus vite tu m'enlèves le turbo vas-y laisse-moi le turbo
mais imagine donc pour quelqu'un ce soit encore un effort et que ça lui ça le ralentisse parce
qu'il ya une phase ou c'est le cas ça dure pas très longtemps mais ça est une phase où c'est le cas
j'ai perdu ce que je voulais dire on dit moi ce que je disais alors tu disais en fait qu'est ce
qu'on doit faire pour quelqu'un qui finalement tdd pour lui il est on les ce n'est pas encore une
habitude pour lui ouais c'est pas encore une habitude mais moi si tu veux quand ça a été
mon cas en fait quand moi j'ai appris à faire du tdd en startup dans un contexte super tendu
plus tendu je crois que c'est pas possible en fait on avait trois mois très oride dans nous
et on avait trois mois pour prouver qu'on était capable de sortir mon produit de le mettre sur le
marché alors j'avais pour moi quelques années on avait passé un an et demi sur la technique
on utilisait qui était sous-jacente qui était outlook à l'époque donc j'avais acquis ça et
justement j'avais tellement souffert pendant un an et demi de régression de galère de bâchins de
truc vraiment ça partait dans j'avais souffert vraiment dur je me dis plus jamais ça plus
jamais ça et tdd était devenu pour moi une en fait c'était une porte de salut quoi en fait et je
me souviens à ce moment de me dire non maintenant à partir de maintenant c'est fini je ne fais
plus rien sans faire du tdd et ça c'est un pattern qui souvent je constate chez les coches
marchent bien ça en fait c'est qu'à un moment donné tu décides de ne plus faire autrement
alors ça veut dire avoir une espèce de confiance un peu aveugle dans le truc hein ça veut dire qu'il
faut faire confiance dans ceux qui ont fait le chemin avant toi de te dire ouais ça a l'air vraiment
trop bien mais moi j'étais en startup on avait tu sais dit trois mois très zori je ne savais pas
si j'allais pouvoir continuer à payer mon crédit je venais de me marier et à un moment donné j'y
suis allé quoi donc je pense que j'ai appris ça dans les pires conditions qui puissent être regardent
tout ce qu'on dit et ça peut marcher alors il ya deux il ya deux choses aussi qu'il faut savoir c'est
juste en fait en rebondissant sur ce que tu dis il faut du courage aussi pour le faire tdd ça c'est
première chose qui est des gens que finalement en fait faut faut du courage pour l'apprendre
une fois qu'il a appris que tu sais le faire et il ne s'est plus du courage et juste de la lucidité et il
faut de la persévérance aussi parce que il y en a ceux qui apprennent parce que quand tu fais du tdd
tu vas retomber sur d'autres problèmes que avant en fait t'avais pas je donne un exemple typique et ça
c'est un truc en fait qu'on a eu avec Xavier yatsla en 2000 2014 2015 on avait tellement
testé nos trucs et on était en mode tdd faut qu'en fait on avait un bullet qui prenait 30 minutes
et oui ah oui après tu as des problèmes différents voilà c'est ça c'est que tu as des problèmes
différents et il y en a qui s'arrêtent aussi à ces problèmes là ils disent ok là je l'ai fait
et finalement je suis pas arrivé et finalement d'accord et après on tombe dans les travers où
non la méthode elle est pas bonne il faut pas en faire ce cas là aussi que j'avais vu de certaines
personnes où je l'ai fait et ça n'a pas marché mais en fait le problème c'est qu'on n'est pas allé
au bout du problème c'est que finalement tdd il va te montrer des problèmes qui existaient déjà il
va les mettre encore plus en décembre moi je l'ai toujours vu comme ça t'ai dit pour moi c'est un
révélateur il t'apporte aucune solution il te dit pas va là ou va là il te dit juste c'est bon ou
c'est pas bon alors l'autre analogie que moi je fais et ça beaucoup de personnes qui me connaissent
savent que je sors tout le temps en fait cette phrase c'est que si tu as un code smell si tu as
quelque chose en fait qui est très mal designé qui est très mal fait et tout tu vois le code tu
dis tu dis what the fuck en fait tu fais le test ça fait what the fuck au carré donc en fait même
si tu veux pas tu vas le voir encore plus avec le test donc ça tellement tellement donc en fait
pourquoi parce que le test c'est ton premier étudiateur c'est ta première spec moi j'adore
que j'ai un script il nomme les tests aspect parce que c'est vraiment ça ce qu'en fait c'est j'ai
quelque chose d'une unité je la teste je lui donne des entrées je m'attends des sorties ça c'est
sur du tdd l'on donne je fais ça je m'attends que ça fasse tel tel tel tel appel et que ça
fasse tel tel tel comportement et ça c'est très c'est très important à mon sens parce que
tdd beaucoup de personnes font l'amalgame en disant que c'est une méthode de test alors qu'en fait
c'est pas le cas on est bien d'accord c'est une méthode pour coder c'est une façon pour coder alors
ça je veux bien qu'on s'arrête deux minutes parce que j'ai un peu fait évoluer les choses là
dans ma tête et cette nuance elle me tu vois avant je crois que j'étais un peu dans la lignée du
de ken back en disant c'est une méthode de design et de conception mais en fait c'est de la merde
c'est pas vrai parce que tdd te donne pas de solution design et si t'as pas de compétences de
design à mettre dedans tu es dans t'es mieux que sans tdd mais tu es quand même dans le caca ça
était mon cas moi je tu veux j'ai j'avais un certain un certain sens intuitif du design qui m'a aidé
longtemps et c'est quand je me suis mis au tdd que je me suis rendu compte que je butais sur des
problèmes de design je suis allé chercher des réponses là j'ai découvert la design paterne mais
tu vois je les ai découvert après en fait tous ces enjeux de conception je les ai découvert
après avoir fait du tdd et là ça a changé ma vie et je me suis bien rendu compte qu'en fait tdd
t'apporte pas de solution donc c'est pas vrai c'est pas une solution de design c'est une manière de
coder une manière de coder oui sauf qu'en fait t'as plein de prérequis derrière pour faire du tdd
et ça c'est le truc que par exemple beaucoup de gens ne voient pas quand ils font des catas
parce que quand ils arrivent dans la vie réelle ils sont complètement perdu alors j'explique il
y a un truc que moi je pousse à mort quand je fais du coaching surtout première chose qu'il faut
faire quand tu veux faire du tdd il faut une architecture claire et il faut une stratégie de
test pour cette architecture je précise qu'est ce que c'est une stratégie test parce que le mot c'est
gros je parle de stratégie test pour les développeurs pas une stratégie test dans le sens
global ce que je veux dire par là c'est que t'as un ensemble de couches si je prends les
architectures 3 tiers ou même on prend l'exact qui ont fait un bon exemple l'architecture
hexagonale donc en fait ce que tu vas retrouver sur l'architecture hexagonale c'est que tu vas
retrouver tes adapteurs d'un côté et tu vas retrouver toute la partie application service et
domaine de l'autre domaine et application service pour moi j'utilise quasiment quasiment que
l'approche on donne dessus ce que je veux dire par là c'est que les applications service ça va
être des tests moqués c'est sûr le domaine éventuellement ça peut être des tests moqués ou
pas ça dépend est ce que j'ai besoin de dépendance ou quoi que ce soit par contre quand je teste la
partie qui est sur l'adapter ça va être des tests alors il y a des gens qui s'appelle ça des
tests d'intégration mais moi je je voudrais pas lancer le débat dessus puisque je pense que le
débat il y a toujours l'union donc ces tests là pour moi je vais utiliser plutôt une approche
une approche en fait tdd classique ou finalement il n'y a pas de moque parce que jd jd donc ça c'est
ta stratégie test que tu appliques ce temps pas de design moi je ne le vois pas comme un pré rocchi
parce que tu peux très bien commencer par faire du tdd sans avoir de connaissance de design
je par contre je le vois comme des choses qui s'amplifient en fait alors je moi ce que je veux dire par
là c'est vrai que c'est ma stratégie parce qu'en fait ça dépend ça dépend de chacun comment
comment en fait il implément mais je la vois comme comment dire comme comme en fait quelque chose que
qui finalement peut me faire du bruit quand je fais du tdd et du coup c'est des problèmes en fait
un peu connex qui peuvent comme tu l'as dit soit si c'est si c'est bien fait ça va amplifier encore
plus dans le sens où vraiment en fait ça va montrer en fait le sens du faire du tdd ou alors
en fait ça peut retomber sur le cas où je l'ai dit par exemple il y a le but d'à 30 minutes
parce que tout simplement pour moi il y a les tests il y a deux types en fait de tests il y a
des tests où je vais finalement faire de l'incrémentale ce que je veux dire par là c'est que par exemple
trois composants qui sont sur trois couches différentes abc c 2 points de b et b 2 points de a
je teste à unétèrement entre gommet si je veux tester b il y a deux façons de faire soit je teste
b en incluant a et je fais de l'incrémentale donc des tests ce que moi j'appelle incrémentale
soit je me dis non en fait je vais moquer à parce que je l'ai déjà testé je voudrais et je voudrais
en fait utiliser des testés uniquement la partie b les deux approches se valent parce que tout simplement
tu peux avoir le cas où finalement tu peux pas moquer à ou alors en fait tu dis bah non en fait
je dois forcément moquer à parce que je veux aller plus vite et du coup les deux facteurs que
moi j'y pense en fait quand je mets une stratégie de test c'est deux choses c'est qu'elles sont mes
dépendances et comment je fais en fait avoir une boucle de feedback plus rapide parce que c'est
ça le but de tdd le premier but de tdd c'est d'avoir une boucle de feedback rapide je sais pas si
tu as le même sentiment que moi quand tu quand tu quand tu développe en tdd moi par exemple si
j'ai pas de feedback je m'essouffle en fait alors que quand j'ai un feedback c'est une espèce de
repos quand je lance le test et que j'ai mon feedback j'ai une espèce de repos et c'est
comme si en fait je prends une pause et après je reprends par la suite ça c'est le sentiment que moi
ça me donne en fait c'est en fait si j'attends trop longtemps pour lancer mes tests j'ai l'impression
que je suis fatigué en fait j'ai fait beaucoup de code et je suis fatigué par qu'en fait dans
l'autre sens j'ai l'impression que je fais un petit pareil après je me repose je fais un petit
pas et je me repose moi ça me donne plus un sentiment d'être guidé et de savoir que je vais
dans le bon sens et vers la dans la bonne direction ça me rassure c'est comme si j'avais un peu une
espèce de ouais tu vois un gps sur moi qui me permet avec j'ai ma boussole mon compas et mon gps
et régulièrement je regarde si je suis sur la piste de mon gps quoi ça me rassure je me dis
ouais ok là c'est rouge c'est est ce que c'est rouge pour la bonne raison ouais c'est rouge
pour la bonne raison ok on fait un pas de plus donc moi ça me donne le sentiment plutôt d'être
ouais d'être confiant sur le fait que je vais dans le bon sens d'accord moi par exemple de ce côté
là où en fait je comprends ce que tu dis moi il m'arrive souvent par exemple quand je n'ai pas
fini ma tâche et c'est la fin de journée par contre le lendemain quand je reprend je sais donc
quel test je me suis arrêté et qu'est ce qui me reste à faire moi j'aime quand c'est comme ça
j'aime bien laisser un test rouge oui alors je ne le pousse pas pour pas je le pousse pas pour pas
sur la sur la siaye mais j'aime bien laisser avec un test rouge comme ça le lendemain quand j'arrive
je me pose pas 15 ans la question j'en suis où ah ouais bah c'est lui allez hop je reprend mon
fil quoi direct c'est exactement ça aussi pour moi c'est magnifique en fait tdd quand tu
quand tu fais du changement de contexte comme par exemple en fait td sur un contexte ça peut être
n'importe quoi contexte au milieu de journée t'as eu un réunion on te bloque quand tu dis à non tu
dois aller forcément et du coup tu t'arrêtes et quand tu reprends tu as déjà quelque chose qui
est clair en fait t'as pas besoin de et du coup ça fait une espèce de deuxième cerveau mais c'est
trop ça en fait tu as raison sur le changement de contexte tu vois moi j'ai l'image qui vient
c'est plus quand je change de branche je suis sur en train de travailler sur un truc j'ai la
besoin de revenir sur une autre branche d'autre gonde pour pour un support je sais pas quoi bon
bah je vais committer là où j'en suis je change de branche et là je n'ai pas je suis vachement
rassuré j'ai pas imposé 50 ans la question de tant à ce que ce que je suis en train de faire je
pas en train de casser un truc mélanger les contextes ah oui mais j'avais essayé j'étais en
train de faire ça ou à main j'ai plus cette classe mais c'est normal c'est sur l'autre branche
juste je me pose pas tant de questions que ça je vais regarder mon test je crie mon test rouge
quand il passe c'est bon allez je committe je pousse et je reviens sur ma branche toi donc ce
que tu dis est très vrai en fait ce coup de changement de contexte est très fort on est déjà à
20 minutes et j'essaye de revenir sur des timebox plus raisonnables et je crois pas que tu es pu
exprimer ce qui était un petit peu le message que tu avais envie de porter par rapport au fait de
maîtriser les méthodes et et pouvoir ou pas s'en écartait en fait alors je vais j'ai une approche
très particulière quand par exemple j'essaie de maîtriser une méthode c'est que généralement
en fait ce que je fais c'est que je mélange un peu entre théorie et pratique et c'est ce que j'ai
fait par exemple à l'époque quand j'ai appris tdd et et quand je sais quand je sais que plus
au moins en fait je commence à peu près maîtriser ce qu'il y a je reviens à l'essence en fait de la
méthode comment je fais ça c'est très simple je vais essayer de chercher qui a créé la méthode
je vais essayer de voir soit les articles soit le livre parce que généralement il y a toujours
un livre qui est derrière donc en fait ce que j'ai fait pour tdd c'est que je suis revenu sur le
livre de canbeck pour l'été des déclassiques qui était dédébaillé exemple et et en fait
j'ai essayé de maîtriser l'essence et c'est là où je commence en fait à passer sur les phases
de pragmatisme parce que pour moi toute approche toute méthode tout outil il ya il y a deux choses
qui a su donc on passe par une phase d'apprentissage de de de dogmatisme il faut passer par ça pour
être en fait pour rester dans le mode puriste pourquoi parce qu'on peut pas justifier ce qu'on
est en train de faire on peut pas justifier en fait les raisons pour lesquelles on les fait de telle
ou telle façon ce que est ce que la référence que moi j'ai si si je ne sais pas si t'as lu le
livre en fait qui fait partie aussi de la collection un peu crape qui s'appelle apprenticeship
paterne il parle de ça il dit ce qu'on appelle en fait un p'ting the cat c'est-à-dire quand tu
attaques une méthode quand tu veux apprendre une méthode oublie tout ce que tu connais en
et en fait va jusqu'au bout de la méthode et après quand tu maîtrise cette méthode là commence
à critiquer avoir dans quel cas tu peux l'utiliser qu'est-ce qui peut être changé quelle partie
où tu peux faire des concessions parce que comme tu le sais notre vie de développeur c'est une vie de
concession fait à chaque fois on est en train de faire des concessions des trade-offs que le
gens ils appellent donc en fait quand je suis revenu sur ce livre là il ya il ya plusieurs
choses que j'ai retenu la première c'est que en fait t'as le droit de brûler des étapes quand
tu veux y aller mais toutes les étapes ne sont pas tu peux pas les brûler il ya des étapes il y a
des actions très très claire donc chaque méthode elle a des bases très très solides et après tu
a des endroits où tu peux jongler un peu et du coup ça dépend de la compréhension des gens ça
dépend de comment ils voient les choses comme tu viens de le spécifier par exemple moi j'ai eu cette
stratégie test pour un pour l'archie exa d'autres ils en ont d'autres ça veut pas dire que moi j'ai
raison et les autres ils en tort ça veut juste dire que moi j'ai exprimé de cette façon ma compréhension
elle est partie sur ça les autres en fait ils l'ont compris d'une autre façon et c'est là où moi
je vois les choses c'est que finalement si t'es tout seul tu vas rater plein de choses l'importance
de la communauté craft c'est ça parce qu'en fait c'est tu peux le voir comme un diamant et chacun
il voit une facette et c'est très intéressant de voir qu'est ce que les autres passettes ils disent
donc je rebondis sur le livre le livre pour être plus précis j'ai appris la première chose que
j'ai appris c'est que ken beck il voulait juste séparer deux choses la première c'est comment je fais
pour avoir quelque chose qui marche tout de suite et comment je fais pour améliorer ce
quelque chose qui marche tout de suite vers quelque chose de plutôt maintenant comme on dit
tout le monde peut le lire qui est simple en fait à maintenir et on dit ceci en ces deux phases là
c'est comme ça en fait qu'il a créé tdd donc il y a le raid qui est en fait la création du test
il y a le il y a le green qui fait que je le fasse passer le plus vite possible il y a le refactor
je suis en train d'améliorer en fait mon code en fait en général et pourquoi en fait je reviens
toujours à ça parce que pour moi c'est dommage que tout le monde fait du tdd et que chacun il a pris
par un moyen et c'est dommage que par exemple tout le monde me parle d'un film alors que moi je suis
pas allé voir le film lui même pour me faire ma propre idée sur le film c'est comme ça que je
que je la vois là par exemple sur le mouvement craft le livre qui est tout déclenché et je trouve
dommage en fait pendant qu'il a moins de succès que les autres qui en fait pragmatique programme
ou il y a même une décision 20 ans qui est sortie il y a pas longtemps et en fait c'est là où moi je
vois que on perd en fait cet essence là parce que parce que soit on va on va se retrouver avec
du dogmatisme pur soit on va se retrouver avec des personnes plutôt avec du pragmatisme mais
sans pour autant avoir les bases pour faire du pragmatisme et en fait ce que ce que j'essaie de
dire c'est que les deux ils sont complémentaires il faut plutôt en fait faire les deux et pas
et faire un passage par les deux et forcément on arrive à une phase où on est un peu hybride sur
certaines parties on est dogmatique sur d'autres on est un peu plus pragmatique c'est comme ça que
moi je le vois à se dire pour moi la maîtrise de tdd c'est c'est le dogme sur certaines choses
et le c pragmatisme sur d'autres choses et là par contre ça diffère d'une personne à une autre
comment à l'interprète la méthode et c'est là où c'est très intéressant parce que c'est là où
il va y avoir en fait un échange entre les personnes pour sur ce côté là où est-ce qu'on est
dogmatique ou est-ce qu'on est pragmatique et là il y a beaucoup de nuances je sais pas si j'ai
j'ai bien répondu à la question bah écoute j'aime bien c'est ton point de vue t'as manière de voir
les choses et je je suis plutôt plutôt assez aligné moi ce que je réfléchissais à comment
rebondir sur ça le truc que ça m'inspire c'est que avec le passage à l'échelle du mouvement le
phénomène que tu que tu évoques où il y a une espèce de perte de de l'essence de la méthode et
des des sujets dont on parle il est il est inévitable en fait c'est parce que au début tu veux avoir
une poignée de passionnés qui vont faire ce travail qui vont chercher à comprendre qui vont se poser
des questions qui parlait au bout du truc et puis plus le mouvement va prendre en ampleur et plus les
termes vont se diluer plus la compréhension des uns et des autres va diverger moins la cohérence
sera possible parce que justement il y aura trop de monde quand tu pars d'une communauté où il y
avait un personne qui se regroupe régulièrement vers une communauté où t'as des milliers de
personnes éclatées surtout sur tout un territoire c'est toi donc et même j'ai envie de dire c'est
la rençon du succès finalement je pense que des gens comme toi comme moi qui ont œuvré pour
que le crave soit connu et atteigne voilà un maximum de monde on doit se réjouir ça parce qu'en
fait c'est normal c'est juste inhérent au fait que le mouvement prenne de l'ampleur et qu'il
est du succès tu m'as rappelé une petite histoire que moi j'avais en 2014 au 2015 en fait on avait
fait un échange entre zénica et 8 lights je sais pas si ça te parle ou pas la boîte 8 lights c'est
d'accord et en fait ce qui s'est passé c'est que il y a eu un software carter qui est venu en
france et moi je suis allé en fait à chicago pour bosser avec les équipes de chicago donc
le bop pour essayer de voir comment ils font du craft et tout et c'était à ce moment là que moi
j'ai découvert que nous on est en france on est très très à cheval sur le méthode on est très
strict c'est pas forcément une mauvaise chose c'est une très bonne chose mais ce que j'ai remarqué
là bas c'est qu'ils étaient extrêmement flexible sur plein de choses et je parle surtout de l'approche
par exemple tdd comment il le font comment ils ils arpent ça donc ils étaient plus plus en mode
au c'est là justement que j'ai découvert cette approche là où on doit être vraiment ferme sur
certaines choses où on est on est on est d'accord ça c'est les actions et on doit être en fait on
se dit non là j'ai un curseur sur lequel en fait je peux jouer est ce que je mets là je le mets
là je le mets là selon les contextes selon les choses et selon les et en fait c'est vrai que
j'avais oublié ce moment là qui est qui était en fait le moment de déclic pour moi sur celle là
parce que à l'époque j'étais il y en a qui me connaissent bien en fait je suis très puriste sur
certains concepts sur certains aspects et tout c'est là où ça m'a ouvert les yeux en disant
mais mais finalement est fait premièrement c'est que l'approche forcément il détient pas la vérité
absolue deuxièmement les les gens qui ont créé ces méthodes c'est plutôt je les vois maintenant
comme des retours d'expérience c'est comme si tu vois j'étais assis ici j'étais en train d'écouter
ton podcast où j'étais en train de de de de voir en fait une interview de quelqu'un donc c'est
une rex en fait c'est c'est grosso modo en fait les les toutes les c'est une rex structuré dans une
dans une dans une méthodologie reproductive exactement c'est ça c'est exactement ça et du
coup à partir de ce moment là tu commence à nuancer tout ce que tu n'es tu commence à se dire
ok là il ya quand même il ya quand même du subjectif il ya quand même il faut pas il faut pas
prendre le truc par contre en fait bien sûr vu que c'est une rex donc il ya beaucoup de choses à
mon sens qui sont bonnes à prendre quand tu quand tu quand tu lis tu dis ok ben là je suis sorti
avec quelque chose il ya quelqu'un il le fait de façon très différente de moi c'est c'est pas mal je
vais peut-être essayer de tester là et c'est là en fait on commence à voir vraiment en fait l'esprit
craft en se disant on détire pas la vérité c'est très sympa d'avoir des gens qui ne sont pas d'accord
avec moi parce que s'il ya des gens qui sont qui sont pas d'accord avec moi c'est quoi l'impact c'est
que ça veut dire c'est des c'est des opportunités d'apprentissage de mon côté et c'est comme ça
que moi je vois les choses c'est des opportunités où moi j'avais pas vu et maintenant je vois
parce que ces gens là en fait ils m'ont ouvert les yeux sur ces opportunités là moi j'aime bien
cette idée que la que les divergences de point de vue soit source d'enrichissement parce que je vois
trop souvent des confrontations qui sont plutôt au contraire anéantissante ou l'une une vision des
choses cherche à convaincre l'autre et tu vois c'est par exemple c'est c'est sous cet angle là que
j'envisage le le débat avec kévin parce que justement on est tellement pas d'accord et de manière
tellement assumé que je me dis chouette on a enfin une occasion d'avoir une discussion construite
autour de ça et pas juste de se taper dessus à coup de non méthiana brutie donc c'est et c'est
sur ça que je te propose qu'on conclut l'épisode toute divergences c'est une occasion de s'enrichir
je trouve que c'est une belle leçon merci ralad si les auditeurs veulent en savoir plus sur ton
travail de suivre ils peuvent venir où alors si ils veulent découvrir un peu plus qu'est-ce que j'ai
fait comme expérience vous pouvez regarder un des anciens épisodes que j'ai fait sur dev journée c'est
fait ou des podcasts en anglais il ya il ya aussi pour le travail ben je suis sur link et din sur
twitter si les gens ils peuvent nous contacter je suis très accessible vous inquiétez pas je
fais pas généralement je réponds si vous n'êtes pas un recruteur il m'aura pas je confirme il m'aura
pas oui je confirme il m'aura pas vous pouvez y aller même si en fait quelques fois je réponds pas
tout de suite mais c'est sûr en fait en général je reviens sur le message et je vous réponds alors
si vous voulez me suivre je suis aussi sur la communauté craft j'ai je fais quelques talks
je j'ai le dernier je les fais je crois avant juste les les vacances en fait de noël et tout
vous avez tech excellence où je parlais où je parlais de pas mal de choses vous pouvez me
trouver sur youtube sur coding legacy code qui ont fait une conf j'en ai fait deux deux épisodes vous
pouvez me retrouver aussi avec youtube en parlant de tcr parce que je parle beaucoup de tcr test
comitane rivards parce que je l'ai fait sur sur des projets réels donc c'est pour ça que je
m'estime que j'ai l'agitimité d'en parler à part ça j'ai mon site web qui est ksouff.com où là
vous avez toutes les infos qu'il y a pour me contacter pour que ce soit voilà merci ralène de rien
quand t'as touché à l'auditeur bah j'espère que t'as apprécié cet épisode si tu as réussi à
rater le clash avec kévin je t'invite à venir sur artisan developer.fr et regarder l'article qui
parle de ça qui fait un résumé d'ici là en plus d'ici qu'on publie cet épisode il y a sûrement
des choses nouvelles qui auront apparu voilà je te remercie et je te dis à bientôt tcho