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 Knopp, Xavier bonjour.
Bonjour Benoît.
Aujourd'hui, je te propose qu'on attaque sur un sujet qui me tient à coeur, qui me tient à coeur,
en particulier ce moment où je suis en train d'enregistrer une formation sur le design de code.
Je fais le constat quand j'accompagne les équipes,
notamment la dernière équipe que j'ai accompagnée où j'avais été mandaté pour amener le TDD
et des équipes à adopter cette pratique.
Je me suis rendu compte que,
démarrer à faire du TDD sur du code legacy,
c'est un petit peu comme si tu me disais, je veux commencer l'alpinisme
et que pour essayer de t'écranpons, je t'amène sur l'imalaya.
C'est en fait le plus dur qui puisse être.
Et du coup, j'en suis arrivé à me dire,
mais avant de pouvoir attaquer ce genre de sujet,
il faut commencer par des étapes intermédiaires.
Et c'est ce qui m'a amené à m'intéresser au design,
parce que je me suis rendu compte que les principes de base du design,
en fait, étaient assez mal connus.
Oui, alors il y a deux sujets dans ce que tu dis.
Effectivement, faire attaquer,
faire du test ou du TDD sur du code existant.
Moi, à chaque fois que je parle de TDD à des équipes, à des développeurs,
c'est ce que je leur pointe tout de suite.
Les erreurs que je constate en général,
c'est d'essayer de les gens qui essaient d'en faire sur du code existant.
Et donc le conseil que moi je donne clairement,
c'est commencer sur du code 9.
Alors quand je dis du code 9,
ce n'est pas forcément un projet 9 qui perd 2-0,
mais ça va être lorsqu'on a un petit développement à faire,
et bien de ne pas venir tout de suite se greffer sur le code existant,
mais de créer par exemple une classe à côté,
et cette classe-là, on a une idée de ce qu'elle doit faire,
et d'essayer de la développer en TDD.
Mais de toute façon,
travailler sur du code existant, c'est ce qu'il y a de plus dur.
Et en plus, c'est assez paradoxal,
parce que finalement ce n'est pas du TDD puisque le code existe.
Donc c'est plus du test after.
Et la première raison qui rend ça difficile,
c'est qu'en général ce code n'est pas testable.
Décidément, je vois les équipes,
elles essaient de commencer à écrire des tests.
Du coup, elles se retrouvent à écrire des palanquées de moques,
et enfin, le setup du test est plus gros que le test en lui-même, tu vois.
Oui, voilà.
Donc on a effectivement ce symptôme-là,
par exemple, le setup du test qui est très gros.
Moi, j'ai aussi vu une équipe qui,
quand je suis arrivé, m'a présenté les tests qu'ils avaient commencé à faire,
et m'avait dit qu'ils en avaient fait un peu,
et puis ils s'étaient retrouvés bloqués.
En fait, tout ce qu'ils avaient écrit comme test,
c'était, ils testaient leurs modules dans les cas ou limites,
c'est-à-dire appeler des méthodes avec des paramètres mauvais, etc.
et vérifier que ça plaîtait des exceptions,
parce que ça, les exceptions en Java, elles ressortent,
elles remontent du code et elles reviennent dans le test.
Ça, ils pouvaient les intercepter.
Donc ils avaient écrit plein de tests de cas ou limites,
et par contre, ils avaient zéro test sur le fonctionnement normal,
même pas un test de fonctionnement nominal.
Pas de cas dominal, quoi.
Voilà, même pas le cas nominal,
et quand on a regardé ensemble pourquoi,
même moi, j'aurais été incapable d'en écrire,
puisque ils avaient un gros code monolithique,
qui en gros était une abrication de dizaines de classes,
mais avec aucun point de sortie, vu de l'extérieur.
Puisque, alors, t'as parlé, c'est le deuxième point que tu avais abordi tout à l'heure,
et, effectivement, je me rends compte,
comme toi, que faire du TDD implique plusieurs principes de conception assez basiques,
mais comme, par exemple, l'inversion de contrôle avec l'injection de dépendance,
c'est-à-dire le fait de créer une classe à un collaborateur à l'extérieur de la classe,
et que ce ne soit pas la classe qui crée elle-même son collaborateur par un new.
Et donc, si je reprends l'exemple de cet équipe-là,
ils avaient plein de new de collaborateurs qui étaient faits à l'intérieur du code,
et vu de l'extérieur, vu du test, on ne pouvait absolument rien faire,
ni faire de moque, ni intercepter une quelconque sortie ou un quelconque résultat.
Donc, venir écrire des tests sur du code existant, c'est très difficile.
Et, évidemment, ce n'est pas du TDD.
Et c'est là où le TDD est intéressant, c'est que, pour moi,
le TDD est une démarche qui va amener à produire du code testable,
puisque, dès le début, on va se poser la question de comment tester
ce que fait ce code.
Et, du coup, ce qui est intéressant dans le fait de dire, on démarre...
Là aussi, c'est à la fois intéressant, et en même temps, on piège,
parce que moi, j'entends aussi, ok, il faudrait démarrer sur un projet new,
dans une situation idéale, comme ça, on repart de la faille blanche.
Je leur dis, oui, mais si vous n'avez pas appris le temps de vous former entre temps,
qu'est-ce qui va se passer ? Vous allez juste reproduire les mêmes erreurs, en fait.
Tu vois, je vois cette espèce de paradoxe où, d'un côté,
il faut acquérir cette compétence sur des nouveaux sujets,
parce que si tu essayes de le faire sur du code legacy, c'est compliqué.
Et de l'autre, acquérir ces compétences de design sur du code 9, en fait,
si tu mets pas un effort énorme et qu'il n'y a pas la marge de manœuvre pour le faire,
c'est-à-dire, dès qu'il va commencer à avoir un brin de pression,
qu'est-ce que vont faire les développeurs, mais ils vont repartir dans ce qui connaît,
et ce qui connaît, par définition, c'est ce qui est amené à la situation
qui rend le code un maintenant.
Oui, et c'est pour ça que finalement, mieux que de s'exercer sur du code existant,
il vaut mieux commencer sur du code 9, et mieux que de commencer sur du code 9,
il faut s'exercer sur du code qui n'a rien à voir.
C'est ce que je préconise souvent.
Donc, finalement, de se faire, par exemple, des codings d'aujourd'hui,
des séances d'entraînement sur des catas, sur des sujets qui n'ont rien à voir,
qui peuvent sembler basiques, calculer des points de tennis,
ou faire du face-buzz, ou faire un calculateur de prix.
C'est un exemple que je prends, c'est ainsi, que je trouve finalement très simple,
et qui quand même permet d'amener pas mal de choses.
Et donc de prendre du temps en marge de son travail,
déjà, pour mettre en œuvre cette méthode,
parce que TDD, c'est pour moi une méthode, c'est une pratique, une façon de faire,
une façon de produire un résultat qui va être du code et du code avec ses tests unitaires.
Et donc cette pratique, il faut vraiment s'entraîner,
et s'entraîner, l'idéal, c'est vraiment de s'entraîner sur quelque chose,
finalement, au départ, de détacher de son travail,
notamment pour ne pas avoir derrière la tête des contraintes métiers
qu'on va avoir dans notre code de tous les jours, etc.
– Ça, je suis complètement d'accord avec toi,
et quand j'anime des catages, je me rends compte qu'il y a ceux qui ont compris le truc et ceux qui n'ont pas compris.
Donc du coup, pour tous ceux qui l'ont compris, c'est top,
parce qu'effectivement, ça leur donne un bac à sable pour s'entraîner.
Et je crois que c'est indispensable.
Moi, même avec des années d'expérience derrière,
je me rappelle avoir pris beaucoup de plaisir à main j'ai oublié le nom de cet événement-là,
qui a lu en fin d'année où tu passes un samedi entier avec des sessions d'une demi-heure,
ou tu... – Un code retrite ?
– Un code retrite, c'est ça.
J'avais adoré cette journée, quoi.
C'était vraiment un moment super.
Mais par contre, t'as tous ceux qui ont eu le déclic,
ou en tout cas qui ont compris le mécanisme,
pas vraiment, on peut pas vraiment encore parler d'avoir eu le déclic,
mais qui au moment de passer à la vraie vie, me disent,
« Bon, ok, on a compris dans le Cata,
le problème du Cata, c'est que par rapport à notre réalité,
c'est un moment donné trop simpliste.
Comment tu fais toi, pour passer du Cata,
pour ceux qui ont réussi à mettre en œuvre dans le Cata,
comme il faut, passer du Cata à la vraie vie ?
– Bah, donc déjà, il faut pas négliger cette phase du Cata,
du Coding Nojo, détaché, etc.
Et c'est là que du coup, on revient à l'étape sur du code nouveau,
et moi, ce que je donne aussi comme conseil, c'est attendez le moment
où vous allez avoir une inspiration.
Moi, je me suis attaqué, je me suis lancé sur le TDD,
un jour où j'avais un développement à faire,
je n'arrive plus à me souvenir ce que c'était,
mais une petite classe qui devait faire du calcul,
ou quelque chose comme ça, et je me suis dit,
« Tiens, là, je le sens bien, ça doit être adapté.
» Donc moi, c'est le deuxième conseil que je donne,
c'est commencer sur du code nouveau,
ou une nouvelle petite fonctionnalité,
ou un nouveau besoin que vous allez avoir dans votre projet,
et quelque chose que vous sentez qui va être adapté,
qui va pas être notamment trop compliqué,
ou trop ardu, ou trop volumineux, notamment par exemple.
C'est vrai que si c'est un tout un module qu'on doit développer
avec probablement besoin de découper dans plein de classes, etc.,
on va tout de suite tomber sur la problématique des moques, par exemple.
Donc ça aussi, c'est un autre conseil que je donne,
c'est commencer par des petites classes qui doivent faire du calcul,
ou de l'algorithmiste,
c'est-à-dire que je donne des paramètres et je récupère un résultat,
on en a plein dans notre code.
Commencez par ça, bien se rôder sur la mécanique du TDD là-dessus,
et ensuite, passer sur des choses impolimes plus volumineuses
qui vont nécessiter du découpage en plusieurs classes,
et donc de passer par les moques.
Ça, c'est aussi une étape qu'il faut aborder après.
Écoute, Xavier, je te propose que ce soit le mot de la fin, merci.
Merci à toi.
Si les auditeurs veulent en savoir plus,
ils peuvent venir ou pour voir un peu ce que tu fais,
est-ce que tu publie?
Sur mon blog, donc le mieux c'est de taper mon nom dans un moteur de recherche,
Xavier Nopre ou Xnopre,
et on trouve facilement mon blog, mon tweet et le reste.
Super, je te remercie de te venir.
Merci à toi Benoît pour l'invitation.
Quant à toi, chère auditeur,
si tu as envie de creuser un petit peu plus ces questions,
si tu as envie de pouvoir t'attaquer et te préparer
à gérer du Code Legacy,
à reprendre l'architecture, reprendre un petit peu ta destinée en main
et la maîtrise sur ton code,
je t'invite dans la Maison des compagnons
sur maison.artisandeveloper.fr
pour venir et découvrir notre formation,
enfin notre cursus de formation,
et il y a en particulier une première formation
et à laquelle tu pourras accéder,
et qui j'espère te donnera envie d'aller plus loin.
Je te remercie, je te dis à demain.