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 Neupre, Xavier bonjour.
Salut Benoît.
Je te propose qu'on parle aujourd'hui des catas et notamment de l'importance des catas et de comment est-ce qu'on les met en œuvre.
Moi je constate deux choses.
D'abord je constate que les gens quand on aborde ces questions de catas,
souvent on trouve ces sujets-là un petit peu trop simplistes et me disent « Ouais mais dans la vraie vie c'est pas ça ».
Du coup j'ai l'impression qu'on zap cette étape alors que pourtant le fait de s'entraîner,
c'est quand même, on l'a déjà évoqué dans un ancien épisode, c'est quand même quelque chose d'important tu vois,
c'est qu'on regarde les footballeurs, ça paraît normal qu'ils s'entraînent les gars.
Dans tous les sports on s'entraîne.
Et pourtant je suis pas convaincu que tout le monde aie saisi cette importance-là de l'entraînement et du catas.
Qu'est-ce que tu en penses ?
Oui je suis tout à fait d'accord, c'est complètement sous-estimé.
On revient à ce qu'on discutait d'un autre épisode.
Ce que je disais, ce que je pointe maintenant de plus en plus,
lorsque j'en parle à des développeurs, c'est que c'est vraiment une méthode.
Et ce que je vois c'est que quand je discute avec des développeurs,
ils me disent qu'ils sont allés voir le dernier frémoire de ceci, qu'ils ont mis en œuvre,
cela etc.
Je discutais il y a quelques jours avec un développeur,
ils me listaient tout un tas de choses qu'il a mis en œuvre,
mais que bon le test unitaire, le TDD, il était un peu passé à côté.
Et en fait je vais faire marquer que tout ce qu'il m'avait listé, c'était des techno.
On est dans un monde, développement logiciel, nous en tant de développeurs,
on est dans un monde où on est au 9-10ème sur des techno, des langages, des frémoires, des librairies.
Et ça finalement ce n'est pas si compliqué à appréhender,
à mettre en œuvre, à trouver des exemples sur le web et tu fais un copier-coller, ça marche.
Tu débeugues, tu regardes comment ça marche etc.
Et en plus avec l'habitude, on acquiert des compétences et des réflexes
qui nous permettent d'aborder ça assez vite.
Le TDD c'est une méthode, c'est une façon de développer
et même pour moi plus c'est un état d'esprit.
Et c'est vraiment une démarche intellectuelle qui est particulière,
notamment de commencer par se poser la question,
qu'est-ce que mon code doit faire, qu'est-ce que mon code doit produire,
comment je vais tester ce résultat là.
Donc c'est vraiment une méthode et c'est là où ça fait toute la différence
par rapport à tout le reste des librairies, des frémoires et des langages.
Et donc c'est pour ça que ça nécessite, à mon avis,
un gros frein pour les développeurs pour y aller
et parce qu'il faut effectivement savoir comment s'y mettre, comment l'aborder,
être aidé, être formé ou accompagné.
Et puis le sujet que tu me proposes de s'entraîner,
donc les catas pour préciser les choses, c'est des petits exercices
qu'on va prendre, sur lesquels on va essayer par exemple d'aborder
un thème sous la forme TDD.
L'idée n'étant pas d'aller au bout, il n'y a pas de résultats,
il n'y a pas de faute, il n'y a pas d'erreur, il n'y a pas de mauvais code,
c'est vraiment l'idée de s'entraîner.
Et l'idée, le mieux pour moi-même, c'est de s'entraîner à plusieurs,
notamment en coding dojo.
Et c'est vrai que souvent ces sujets-là qu'on peut trouver peuvent sembler simplistes.
Et moi j'insiste souvent sur le fait que oui, ça peut paraître simpliste,
mais allez-y, essayez, mettez-vous devant votre clavier
et allez-y coder pendant une demi-heure et essayez de le coder en TDD
ou essayez de le coder en appliquant différents principes de design, etc.
Et finalement plus le sujet va être simple,
plus on va pouvoir se concentrer sur l'objectif qu'on est en train d'essayer de travailler.
Oui, il y a deux points qui me font réagir dans ce que tu dis.
D'abord, l'idée que le TDD, comme le design, comme le refactoring,
pour moi ce sont trois compétences que je vais appeler des compétences profondes
au sens du deep work tel que l'entend Carl Newport,
c'est-à-dire des compétences qui sont de l'ordre du savoir-faire acquis,
quelque chose qui va demander une expérience, un peu comme le maître Forgeron,
qui va apprendre à forger pendant des années.
Et alors que j'oppose à ça les frameworks et les langages,
qui sont des compétences peu profondes, des compétences plus superficielles,
où finalement apprendre un nouveau langage, c'est pas si compliqué que ça,
en quelques jours tu peux apprendre un nouveau langage,
apprendre ces subtilités ça va prendre plus de temps,
mais commencer à produire du code dans un nouveau langage et dans un nouveau framework,
sous une, deux, trois, allez, quatre semaines si c'est tes premières fois,
on va y arriver.
Par contre, apprendre à structurer profondément ton code et préparer l'avenir,
ça je pense que ce sont des compétences vraiment profondes
qui demandent du temps, qui demandent de l'implication
et qui sont très loin d'être aussi répandus que ce qu'on pourrait l'imaginer.
Et le deuxième point qui me fait agir, c'est sur le Cata.
Moi je me souviens de ce code retreat quand on avait passé une journée sur le jeu de la vie,
ce que j'avais trouvé super.
Le truc même qui avait été un peu violent pour moi,
c'était de devoir jeter le code au bout d'une demi-heure.
Oui, oui, ça c'est...
Et ça quand je m'amuse à l'imposer en Cata,
quand on fait des petits Cata, où on a une heure et demi devant nous,
on va faire trois itérations d'une demi-heure,
je me rends compte que c'est toujours aussi violent pour les gens.
C'est tellement pas habituel chez nous ce truc,
voir qu'on a envie de finir le problème.
Mais non, mais l'enjeu d'un Cata n'est pas de finir le problème justement,
il est de s'entraîner, d'échanger des points de vue,
d'apprendre de l'autre, de...
Tu vois toutes ces choses-là.
Oui, oui, alors ça, cette histoire de jeter du code,
par exemple dans les codes retreats,
déjà du code mort dans un projet,
un développeur a du mal à le supprimer, on ne sait jamais, au cas où,
au cas où ça pourrait servir, on ne se souviendrait pas comment on l'a fait.
Alors en plus, en code retreat, du code que tu viens de faire,
qui marche, qui fait passer les tests et tu jetes tous, c'est...
Je me rappelle, tu as eu mal au ventre les premiers fois.
Mais sans aller jusque là, toi par exemple,
un petit coding dojo entre millier et deux,
pendant une heure, une heure et demi,
on ne va pas aller au bout,
et puis au bout d'une heure et demi, on quitte la salle,
on retourne à nos activités, personne ne sait ce que devient le code,
à part celui qui a peut-être animé le coding dojo.
On ne voit pas que le code, il va être jeté,
ou à la limite, on va le mettre de côté pour pouvoir retourner le voir,
et on ne le fera pas forcément.
On ne jette pas ce code, mais cette idée de s'entraîner.
Mais j'en reviens à ce que je disais tout à l'heure,
je pense que effectivement, si le sujet...
Moi, j'essaie toujours de trouver des sujets qui soient vraiment simples
et compréhensibles par tout le monde.
Par exemple, je préfère proposer de compter les points de tennis
que les points de bowling.
Tout simplement déjà, parce que les points de bowling,
moi, je ne sais pas comment ça marche,
et très peu de monde sait comment ça marche, et c'est compliqué.
Mais tu prends par exemple compter les points de tennis,
bon, finalement, ça a beaucoup de monde connu,
donc déjà, on n'a pas à se poser la question
de comprendre le boseau pour l'exercice,
des règles métiers simples pour comprendre l'exercice.
Et puis on s'aperçoit, mais ne rien,
petit à petit, que ce n'est pas si facile.
Mais ce qui est important, c'est effectivement de se mettre le focus.
Par exemple, quand j'anime des codignes d'aujaux,
j'essaie de vraiment faire attention à ce qui est un objectif pédagogique
au code d'aujaux.
Si ça va être le TDD, on va mettre de côté,
on va chanter, on va trancher net,
tout autre sujet de discussion qui pourrait partir sur autre chose.
Et vraiment parce qu'on est là pour s'entraîner
sur quelque chose de précis.
Et je pense que, je reviens à ce que tu disais tout à l'heure,
par rapport au langage, aux librairies, etc.
Il y a aussi un point, c'est que pour les non-développeurs,
les chefs de projets, les commerciaux, etc.,
eux, ça leur parle un langage, un framework de vendre ce produit.
On l'a développé dans tel langage, dans tel framework,
avec Docker et des mots comme ça qui claquent.
Ça, c'est bon.
Ça, ça marque et ça parle à tout le monde,
au vendeur, au client, etc.
Par contre, les tests unitaires qui sont là ou qui ne sont pas là,
déjà ça, c'est quelque chose qui pourrait se voir, se mesurer.
Mais c'est lié à la qualité.
La qualité, c'est toujours un problème,
c'est toujours quelque chose qui est plus difficile à appréhender.
Et le TDD, qui est une méthode, une façon de faire au quotidien
par le développeur, et ça, ça ne se voit pas du tout
dans le résultat final.
Ça ne se voit pas.
Le résultat sera très différent si c'est en TDD ou pas.
Mais tu vois ce que je veux dire, dans le...
Du plus utilisateur, à part par l'absence de bug,
tu le vois moins.
Pour l'utilisateur, pour le client, pour le commercial
ou le manager, cette pratique du TDD,
dans le quotidien du développeur, ne se voit pas,
ou est très mal comprise.
Et ça, ça n'aide pas non plus à pousser, à promouvoir cette pratique.
Oui, donc ce que tu dis, c'est un jour,
on peut rêver d'un jour où les commerciaux,
au lieu de se faire des petits plaisirs
sur les frameworks qui auront été utilisés,
pourront dire, cette application a été développée
selon les règles de l'art du craftmanship,
et notamment de l'intégration continue et du TDD par exemple.
Oui, alors c'est même pire que ça,
parce que de l'intégration continue,
moi, dans ce que je vois, souvent, c'est vendu.
Mais parce que ça se voit, regardez, on a un Jenkins,
on a une intégration contenue, ça tourne, ça fait ci, ça fait ça.
Mais après, à charge des développeurs,
de se débrouiller pour produire ça.
Et TDD, pas TDD.
Et moi, je rêve du jour où les non-developpeurs,
tous ceux qui gravitent autour des développeurs,
pousseront ça.
Alors là où j'ai de l'espoir, c'est que je l'ai vu,
je le vois des fois, et je me souviens d'un projet il y a plusieurs mois,
où dans une rétrospective entre développeurs,
on a discuté TDD, etc.
Et d'un coup, le product-honneur est intervenu,
en disant, écoutez, je vous écoute depuis tout à l'heure.
Ce que je comprends d'après Xavier, c'est que c'est quelque chose d'important.
Vous avez l'air tous d'accord pour dire que c'est important.
Vous avez l'air tous d'accord pour dire que vous n'êtes pas compétents,
Xavier peut vous aider, je faisais partie de l'équipe en tant que développeur.
Xavier peut vous aider.
J'enlève l'équivalent de, disons, deux jours de points.
Enfin, j'enlève tout un tas de points de velocité à la prochaine intération,
et vous prenez un jour de jour pour vous former,
vous bloquez un jour de jour pour vous former dès demain.
Et ça, c'est vraiment passé comme ça.
Et ça, ça m'a fait rêver, quoi, d'avoir vraiment un product-honneur
qui est là et qui à un moment prend conscience que c'est quelque chose d'important,
que ça va, il voit la valeur que ça a, il voit que ça va apporter de la qualité,
il entend que quand les développeurs en parlent,
il y en a qui sont à l'aise, d'autres pas à l'aise, et que c'est ça,
le frein, et il pousse et il fait la promotion de ça.
Mais c'est encore trop rare.
Vous avez écouté Xavier, je te propose que ce soit le mot de la fin.
Merci d'être venu.
Si les auditeurs vont en savoir un petit peu plus sur ton activité,
est-ce que tu publie, ils peuvent venir où ?
Le mieux, c'est d'aller voir sur mon blog qui n'est pas très actif
et qui se trouve facilement en cherchant mon nom Xavier Noppre
ou Xnoppre sur un moteur de recherche.
Super, merci Xavier d'être venu aujourd'hui.
Merci pour l'invitation Benoît.
Quant à toi, chers auditeurs,
si tu as envie de creuser un petit peu plus ces questions,
si tu as envie de comprendre les principes clés de base du design orienté objet,
je t'invite à rejoindre la maison des compagnons
sur maison.artisandeveloper.fr
ou venir tout simplement rejoindre la communauté des artisans développeurs
sur www.artisandeveloper.fr
Je te dis à demain.