Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui, je suis avec Xavier Knopr, Xavier bonjour.
Bonjour Benoît.
Aujourd'hui, j'avais envie, je te propose qu'on parle d'un sujet,
qui était un peu le sujet, qui était quelque chose qui m'avait marqué lors de notre premier échange,
c'est le déclique des DDD.
Ce que j'appelle le déclique des DDD,
c'est ce moment où tu percutes vraiment le DDD,
ou un peu comme Néo dans la matrice,
tu te mets à comprendre le truc et à le vivre de l'intérieur,
et à décoder le monde qui est autour de toi.
Et ce que je trouve dingue, c'est que tant que ça passe, déclique.
Je trouve que c'est assez difficile de faire comprendre à ceux qui n'ont pas eu de quoi ils en retournent.
Et moi, depuis que j'ai eu ce déclique, et plus je veillis, et plus je mets en œuvre le DDD,
et plus j'ai du mal à comprendre encore,
ou alors il faut vraiment que je fasse un effort pour revenir à cet état de
« je ne connais pas exactement de quoi il en ressort »
et du coup, ça a une influence forte dans la manière de le transmettre.
Du coup, je suis curieux que tu me dises que si on pense et peut-être évoquer ton déclique des DDD,
c'était quand toi ?
Est-ce que tu te souviens du moment où tu as tilté, ou tu as percuté sur le DDD ?
Non, alors je ne me souviens pas vraiment.
Moi, j'ai découvert l'agilité en 2007 et le DDD test militaire et tout ça, un peu dans la foulée.
Je me souviens juste qu'un jour, j'avais un développement à faire,
et non, la première étape, c'est un collègue qui nous avait montré sur un cas de disons de calculette,
et j'avais trouvé ça bateau, je ne voyais pas l'intérêt, je ne comprenais pas le truc,
mais je l'avais quand même noté dans un coin de ma tête, et puis je me souviens du jour,
un jour où j'avais un petit développement plutôt de calcul à faire, et où je me suis dit,
tiens là, ça pourrait être le bon cas facile,
et là je vois un peu comment je pourrais m'y prendre,
et je m'étais essayé sur ce cas-là assez simple, et effectivement ça avait marché.
Donc je me souviens de ce premier expérience.
Je me souviens que par la suite, j'ai eu plusieurs...
En fait, tu parles d'un déclic, alors j'aime bien ton image de la matrice,
ou d'un coup tout s'illumine, et tu vois à travers...
J'aime bien cette image-là effectivement, c'est un peu ça,
et moi par contre, pas précisément, mais je me souviens en fait d'avoir eu plusieurs déclics,
plusieurs déclics, peut-être deux, trois déclics notables,
où effectivement je me suis dit, ah oui, mais c'est ça.
Je me souviens notamment d'un déclic,
et c'était peut-être le deuxième je crois,
où c'était de la correction, c'est-à-dire que j'avais du code qui commençait à être testé,
avec du test unitaire, et à un moment il y a eu un problème,
et j'ai fait de la correction pilotée par les tests.
Et ça je me souviens que j'avais trouvé ça mais génial,
et que je m'étais retrouvé un peu bête à me dire,
à sentir au fond de moi que j'étais sûr de moi sur la correction que je venais de faire,
et que j'avais même pas besoin de rebulder toute l'application et de tester ce correctif,
tellement j'en étais sûr grâce aux tests unitaires,
donc ça avait pris très peu de temps,
et là vraiment j'avais eu ce déclic.
Donc voilà un peu les souvenirs mais assez vagues.
Par contre, quand j'essaye de transmettre aux gens un peu de les aider à aller vers les tests unitaires et le TDD,
ce qui me frustre, et je pense que ça rejoint un peu ta question,
c'est effectivement, je sens que tant qu'il n'y a pas eu ce premier déclic,
un minimum d'expérience vécue, c'est difficile d'en voir l'intérêt,
et moi ce qui me frustre c'est que finalement je ne sais pas pourquoi je me suis accroché,
pourquoi j'y ai cru, et qu'est-ce qui m'a amené jusqu'à ce déclic.
Voilà pour moi.
Ce qui est intéressant là où ça rejoint ma propre expérience,
c'est que moi le déclic, j'ai un souvenir, pas forcément de l'instant,
d'une période de temps, enfin du démarrer un nouveau projet,
et j'ai fait mes premiers TDD sur des Get Set,
et je me souviens d'une manière par contre encore assez marquée des motets que ça me donnait,
mais attention pour tester des Get Set, un truc super puissant,
et ce renversement dans le mode de réflexion m'avait marqué,
et pendant cette période là, quand je fais mes premières armes,
que je comprends toute la puissance et l'utilité du truc,
et ce que je trouve intéressant dans ce que tu dis dans mon expérience,
c'est que finalement on a commencé sur des choses plus simples en fait,
et c'est vrai que quand j'arrive sur un projet et qu'on me dit
« Benoît, nous, comment on fait des tests, comment on fait du TDD,
et que tu as du code legacy, c'est bon les mecs,
alors je vous explique, vous attaquez juste parce qu'il est le plus dur,
c'est-à-dire que vous faites du refacto, de code existant,
tout en apprenant le TDD, tout en apprenant tout ça,
ça fait beaucoup d'un coup, c'est-à-dire que vous n'avez non seulement pas les compétences,
mais en plus le contexte, c'est le pire qui puisse être pour mettre en oeuvre,
donc il va falloir du temps, et dans ton exemple,
je retiens, tu as commencé sur des cas simples en fait.
Oui, oui, oui, tout à fait.
Et donc, moi, quand j'essaye de partager mon expérience avec des équipes,
je tire les leçons de mon expérience et de ces années
où j'ai expérimenté tout un tas de trucs, où j'ai fait plein d'erreurs,
et où j'ai eu des galères,
et effectivement, dans les conseils que je donne, les premiers conseils basiques,
c'est effectivement de commencer sur du code nouveau, sur des cas simples,
et effectivement, comme toi, quand je rencontre des équipes qui me demandent de venir les aider,
en général, quand on commence à discuter, où je leur demande un peu les tests qu'ils ont essayés de faire,
presque systématiquement, les gens ont essayé d'écrire des tests après sur du code existant.
Donc quand j'arrive en leur disant comme toi, tu viens de le dire,
quand j'arrive en disant, mais attendez, ce que vous avez essayé de faire là, c'est le plus dur,
parce que votre code n'est pas testable,
bon ben, c'est vrai qu'en général, ça a tendance quand même à les rassurer.
Par contre, c'est vrai qu'il y a un peu de public,
on parle un peu de la question, c'est quand même la difficulté pour se mettre au TDD quand même.
Les gens qui ont essayé et qui sont un peu cassés les dents, en général,
cela, j'arrive bien à les aider, parce que très vite, je leur dis,
vous avez essayé sur du code existant, c'est le plus dur.
On va essayer sur du code nouveau, je leur donne quelques petits trucs et astuces pour démarrer,
et comme ils ont essayé, il y a quelque chose qui se débloque très vite,
alors peut-être qu'on est proche du déclic, qu'on n'en est pas loin.
Par contre, il y a un autre public, celui qui est les développeurs
qui n'ont jamais essayé, ça, c'est quand même beaucoup plus difficile, je trouve,
de les emmener parce que lorsqu'on leur propose de faire sur du code simple,
notamment des petites classes de calculs qui n'auront pas besoin de moque,
parce que sinon, ça rajoute une difficulté ou il n'y aura pas trop de collaborateurs,
ben, ça leur semble trop simple, en fait, trop bateau.
Et finalement, il donne l'impression de ne pas avoir l'intérêt,
c'est tellement c'est simple, on a l'impression que les tests vont nous aider
quand c'est plus compliqué.
Donc, c'est un peu ça, c'est que du coup, les gens soient s'y mettre sur du code existant,
et c'est compliqué, ou soit vont s'y mettre lorsque ils vont déjà finalement être en difficulté.
Je pense qu'un message important, c'est comme tout un tas de choses,
on fait souvent l'analogie avec les arts martiaux ou d'autres pratiques,
par exemple, sportive ou autre, c'est de commencer sur des choses faciles,
ou en temps normal, on est à l'aise pour s'essayer au TDD.
Oui, c'est clair que si je voulais monter l'avrest,
ça paraît très débile de dire je vais me former pendant que je monte l'avrest.
Voilà, tout à fait, c'est ça.
C'est ça.
Donc, je ne sais pas comment rebondir sur ton analogie,
mais c'est un peu ça aussi bien pour monter l'avrest
en termes de conditions physiques, de techniques, d'équipements,
de découvertes de l'équipement.

Et le problème en montant l'avrest comme ça,
c'est que tu vas rencontrer des difficultés que tu vas devoir absolument.
Tu auras l'impératif de surmonter ces difficultés,
parce que ton objectif, c'est l'avrest.
Alors que, ça semble évident à tout le monde,
que tu ne vas pas aller attaquer l'avrest comme ça,
que tu vas te préparer dans ton coin,
et que en te préparant dans ton coin,
soit sur de l'escalade ou du glacier,
tu vas pouvoir travailler des gestes que tu vas pouvoir répéter,
ou tu vas pouvoir rencontrer des difficultés à moindre échelle,
mais dans un contexte plus facile, plus serein, sans objectif.
Ça, c'est effectivement l'analyse qui peut être forte,
là, peut être intéressante sur l'objectif.
Parce qu'effectivement, souvent aussi,
les développeurs essaient de s'y mettre dans leur quotidien,
avec des contraintes et des impératives de production,
de choses à produire dans des délais finis.
Et c'est ce que je dis toujours,
se mettre au TDD, c'est un investissement, ça va prendre du temps.
Même si moi, je considère que le retour soit un investissement,
ou moi, je développe plus vite en mode TDD,
mais dans les premiers temps,
il y a forcément un investissement d'apprentissage
qui va prendre du temps.
Et donc, c'est pour ça que c'est important
de soit se dégager du temps,
avoir plus de mou sur nos délais,
pour faire des choses,
ou soit se dégager du temps complètement à part
de notre vie de tous les jours,
dans des coniques d'aujourd'hui,
des choses comme ça, pour s'essayer,
pour se former, pour s'entraîner,
se confronter à des difficultés,
voir comment les traiter.
– Eh ben écoute, pour quelqu'un qui ne savait pas trop comment rebondir,
je trouve que tu as plutôt bien contribué.
Je te propose que ce soit le mot de la fin.
Merci Xavier.
– Merci à toi Benoît.
Quant à toi chère auditeur,
si tu as apprécié ce podcast,
je t'invite à venir nous rejoindre
sur la communauté des artisans développeurs
sur artisanddeveloppeurs.fr.
Et je sais que Xavier fait des supers screencasts
en ce moment, sur notamment le TDD,
le clean code et tout ces choses-là.
Et je t'ai mettrai le lien, je crois que c'est
xnop.blog…
– Quoi déjà ?
– .fr.
– .fr.
– Voilà, mais sinon,
on tapait Xavier Nob sur un moteur de recherche
et on me trouve facilement.
– Super.
À demain.