Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
J'entends souvent cette question, mais par où est-ce que je dois attaquer mon code legacy ?
Alors avant de répondre à cette question, j'ai une petite annonce d'auto-promotion à faire.
Le module 4 qui porte sur comment écrire des tests unitaires du cursus Artisan Developer
est encore disponible dans la maison des compagnons à un prix spécial de lancement.
C'est jusqu'à demain soir, donc si tu veux en profiter maison.artisan-developer.fr.
Voilà, c'était la petite page d'auto-promotion.
Revenons à la question de comment est-ce que j'attaque du code legacy ?
C'est-à-dire, comment est-ce que je fais pour reprendre mon code ?
Tu as certainement l'intuition qu'il va falloir écrire des tests à un moment donné,
en tout cas si j'en parle, c'est qu'à un moment ou un autre on va forcément trouver des tests.
Et c'est finalement assez simple.
Tu attaques le code legacy par là où tu le modifies.
Fondamentalement, soyons clairs, c'est inutile de reprendre un code qui marche et qui ne change pas.
Donc, à la fois, ça peut être effrayant d'attaquer du code legacy,
parce que tu te retrouves avec des systèmes qui ont 10 ans hommes de développement,
à une équipe de 5 à 10 personnes, tu dis mais comment on va faire pour rattraper ça ?
Et en même temps, finalement, si tu attaques par là où tu modifies, si tu regardes bien,
tu modifies rarement tout le code.
En fait, il y a souvent toute une partie du code, et dans les vieux systèmes probablement,
une partie du code soit qui ne sert à rien, mais qui en tout cas ne bouge pas.
Et ça, finalement, tu n'as pas besoin de t'en préoccuper.
Et donc, la règle d'or pour attaquer le code legacy est simple.
Toujours tester tes modifications.
Parce que la grande question, c'est comment je m'assure que je ne casse rien.
Et donc, tu vas avoir besoin d'écrire des tests.
C'est-à-dire, quand tu modifies ton code, comment est-ce que tu t'assures que tu n'as rien pété,
que le truc continue de fonctionner ?
Évidemment, si tu écris des tests, tu me connais.
Ma recommandation, ça va être de le faire en TDD, qui est pour moi la seule manière d'écrire des tests valables.
Mais soyons clairs.
Au début, tu travailleras forcément en partie sans filet.
Tu ne pourras probablement pas tester tous les impacts potentiels,
surtout le code du truc que tu es en train de changer.
Alors, parfois, il y a peu de liaison, il y a peu de couplage sur le code que tu es en train de lire.
Et là, tu as du bol, vas-y, c'est des endroits faciles, attaques par ça.
Et puis, il y a des fois où, probablement, assez rapidement,
tu as envie de refactoriser des choses qui sont des espèces de Magohamot,
du code qui ont des ramifications de partout.
Et ça, ça sera plus compliqué.
Et tu ne pourras pas tout vérifier.
Déjà, si tu es simplement conscient des impacts potentiels,
ça sera déjà très bien.
Donc, au minimum, à minima, le moindre que tu puisses faire,
c'est tester le code que tu es en train de modifier,
c'est-à-dire la ligne de code que tu es en train de modifier,
fait en sorte qu'elle soit testée et couverte par un test.
Alors, ça peut s'engler parfois ridicule,
parce que tu vas déployer une énergie dingue, parfois, pour tester quelques lignes.
Mais petit à petit, tu vas renforcer ta couverture.
Tu vas nettoyer ton code.
Tu vas prendre confiance en toi.
Tu vas commencer à amadouer cette espèce de bête que tu as devant toi.
Et un jour, il y aura un point de basculement.
Les modifications deviendront plus fluides.
Tu te sentiras à l'aise dans ton code.
Tu auras vraiment le sentiment d'avoir repris la maîtrise sur ton code.
Mais vraiment, pour ça, j'insiste, le plus dur, ce sont les premiers tests.
Ce sont ceux qui ont l'air ridicules, parce que tu testes un truc évident, parfois.
Combien de fois on m'a dit, enfin, Benoit, c'est ridicule de tester des Get Set ?
Oui, mais pour moi, c'était déjà énorme.
C'est ça qui m'a fait progresser.
J'ai commencé à écrire des tests, on t'a aidé sur des Get Set.
Oui, c'était basique et ridicule et aujourd'hui, je ne pense pas que je le referai.
Mais c'est ça qui m'a permis de progresser.
C'est ça qui m'a permis d'en arriver là aussi aujourd'hui.
Le plus difficile, ce sont les premiers refactoring.
Ceux qui vont amener à créer une classe pour deux lignes de code.
Ça va te sembler parfois lourd, dingue, un peu too much, un peu superfaitatoire.
Mais accroche-toi.
Respecte la règle d'or du code legacy.
Toujours tester ces modifications et tu verras le jeu en vola chandelle.
Alors forcément, je suis très curieux de ton retour.
Est-ce que tu essayes ça ?
Quel retour tu as ?
Quelles sont tes points de galère ?
Parce que souvent, les gens, quand ils rentrent dans cette démarche-là,
assez rapidement on butent sur des choses,
mais qui ne sont pas si énormes que ça,
qui ne sont pas si difficiles que ça à dépasser.
Donc si jamais tu essayes ça, si tu essayes d'appliquer la règle d'or,
si tu dis aujourd'hui, allez, aujourd'hui, juste aujourd'hui,
je me donne la journée pour essayer cette règle d'or,
voir comment je pourrais tester ces trois lignes de code
là que j'ai à écrire.
Ok, ça me prendrait peut-être une demi-heure de les écrire en tant mal,
et là je vais y bouffer la journée.
Mais si tu décides de faire cet investissement,
si tu décides de tester ça et que tu bloques,
dis-le moi par email, Benoît, Robase Artisan Developer,
et je te file un coup de main,
j'essaye d'aider pour voir comment je peux te dépatouiller,
et si tu y arrives, alors encore plus, envoie moi un email
et tu auras la même adresse,
benoîtarobaseartisandeveloper.fr
Je te dis à demain.