Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Guillaume Vincent, Guillaume bonjour.
Salut Benoît.
Les auditeurs ne te connaissent pas encore,
est-ce que tu peux en une minute nous donner les grandes lignes de ton parcours ?
Oui, c'est très simple, je suis artisan logiciel,
Software Craftman, je travaille pour une boîte américaine qui s'appelle Red Hat.
Je suis fan de TDD, test de clean code.
Voilà à peu près, je développe depuis 10 ans.
Et tu me disais que chez Red Hat, et ce sera le sujet de cet épisode,
je te propose de travailler sur le code legacy,
chez Red Hat, tu étais un peu le monsieur code legacy.
Qu'est-ce que tu fais exactement dans ce cadre-là ?
Je suis monsieur code legacy sur du front, je m'amuse, je transforme des applications front,
j'aide des gens à transformer des applications front de certains frameworks à d'autres frameworks.
Parce que quand tu as du code qui fonctionne pour que le jeté le fait évoluer,
et on change le monde du front et du web évoluent très vite,
il faut être capable d'évoluer aussi vite et d'utiliser les bons outils au bon moment.
Voilà, j'entame des migrations d'applicatif,
la dernière en date étant une migration d'angulargie S verre React.
C'est des gros chantiers, en général, ce genre de trucs,
ça passe par une réécriture totale, comment tu t'y prends à faire ce genre de choses ?
Alors j'essaye, sur la dernière en date que j'ai faite,
j'ai essayé d'extraire du code métier en JavaScript pour pas avoir à tour et à écrire.
Je passais d'angulargie S à React, donc j'allais avoir toute la partie HTML transformée en JSX,
pour ceux qui connaissent, mais toute la partie métier, toute la partie parsing de données,
gestion des événements, tout ça, je voulais pas avoir à leur écrire,
donc j'ai introduit Redux, un outil Nibirri pour faire une gestion d'état,
avec des tests, puis on en parlera peut-être après,
plein de tests fonctionnels en fait et des tests d'intégration,
et avec les tests plus le code qui allait pas changer,
c'est-à-dire que j'allais réutiliser Redux dans le nouveau framework en React,
et puis après j'ai introduit composant par composant, j'ai modifié composant par composant,
jusqu'à avoir la dernière version qui aille bien sans l'ancien framework.
Ok, d'un point de vue design, comment tu t'y prends pour faire un genre de choses,
tu mets en place des architectures type, architectures hexagonales,
tu fais un découpe-l'âge fort, comment tu t'y prends ?
Alors j'ai pas des applications qui sont assez gros pour faire de l'architecture hexagonale,
pour faire du domaines driven design, mais Redux en lui-même est une librairie,
un outil qui t'oblige à découpler énormément ton code en événement,
et du coup qui rend ton code beaucoup plus testable.
Donc le fait d'introduire Redux, Redux Saga ou ce genre de choses,
t'oblige à découpler ton code et à le rendre plus maintenantable et plus testable surtout.
Et comme j'introduis des tests souvent sur du front ou du code où il n'y a pas beaucoup de tests,
ça m'oblige à découpler.
Donc je découpe, comme à chaque fois je travaille sur du code legacy,
je découpe ce qui est facilement découpable, des fonctions, des utiles,
que j'arrête de mettre dans des fichiers utiles et que je nomme correctement,
et petit à petit composant après composant, tu peux améliorer le code et découpler correctement.
Finalement, pour faire ces passages-là, tu t'appuies sur du Redux,
et ce que je n'ai pas bien compris, c'est comment tu substituées,
ça veut dire que pendant un certain temps, tu as les deux freins morts qui tournent en parallèle
et puis petit à petit, en fait, tu as des... C'est quoi ton unité de travail ?
C'est composant par composant, page par page, tu migres ou c'est par morceaux entiers ?
Est-ce que tu arrives à faire des mises en prod quotidiennes
ou est-ce que tu es obligé d'attendre un peu des gros changements d'avoir cassé des gros morceaux ?
Alors, chez Redat et dans l'équipe dans laquelle je travaille,
c'est pas vrai pour toutes les équipes dans laquelle je travaille,
on pousse en production très souvent à chaque comite.
Du coup, c'est posé la question de savoir comment on faisait pour faire une migration d'angulargiès vers React.
Alors, ce qui s'est passé, c'est qu'au début de la migration, j'ai fait des comites,
comites par comites, et on a lancé toute la CIA,
pour voir si ça tournait et si on pouvait merger les deux.
Alors, il se trouve que l'appli qu'il fait tant pas très gros, on a décidé de pas faire ça,
c'est-à-dire de pas merger à chaque fois et de faire un gros changement.
Donc là, le rechangement, il est en cours de review.
Mais dans l'idée, c'était tout à fait possible d'avoir les deux frémoires comme parallèles,
de modifier composants par composants, les composants qui sont des composants visuels,
qui ne sont pas très intelligents, qu'on peut modifier.
Donc, on commence par les composants les plus faciles.
Après, on passe aux pages, les pages qui vont faire des requêtes à pays et qui vont instantier ces composants.
J'ai fini par le routeur, la gestion de l'authentification et toute la partie de la glue qui devient assez complexe.
Et voilà, l'idée, c'était commencé par le bas de l'arbre, en fait,
parce que ce casse est rigolo dans le Ouest.
On se parle des feuilles qui ramènent doucement vers le tronc.
Exactement.
Et la raison pour laquelle on n'a pas poussé en prod les deux, c'est que ça faisait un bundle,
un fichier javascript un peu trop gros, parce que tu doubles presque toute la taille des fichiers.
Donc du coup, parce que l'applicatif n'est pas très gros,
parce qu'on ne voulait pas doubler la taille du bundle,
on s'est permis de faire un gros changement et ça m'a pris à peu près deux mois, donc ce n'était pas non plus.
Mais je me suis assuré que chaque modification, en fait, passait sur la suite d'intégration et nos tests,
pour m'assurer que si demain, on devait aller en prod et introduire forcément,
parce que je ne sais pour quelle raison on aurait pu le faire.
Et du coup, concrètement, ça veut dire que à chaque fois que tu reviens un petit bout, là tu faisais en tête des dés.
Oui.
Alors concrètement, ça fait des mois que je prépare cette chose-là.
L'introduction de Reduc, je l'ai fait presque quand je suis arrivé dans mon équipe,
parce que je voulais introduire des tests unitaires dans du front.
Donc ça fait des mois en fait que j'ai utilisé l'ancien framework en introduisant Reduc,
ce qui m'a introduit du découplage, ce qui me permet de faire des tests unitaires.
Et petit à petit, en fait, jusqu'au moment où on ne fait le pas et on décide de tout changer tous les composants,
qui sont des composants visuels en gros.
D'accord, ce que tu dis, c'est que petit à petit, tu as commencé par grignoter de l'intérieur le framework existant,
enfin la base existante.
Exactement.
D'accord.
Et ensuite, parce que le problème souvent, c'est celui-là, c'est que quand tu veux commencer à mettre du TDD en place,
sur une base legacy qui n'a pas été designée avec du TDD ou avec des tests automatiques,
ça devient vite très difficile.
Tu te retrouves vite à tirer une énorme pelote de laine.
Tu crois que tu vas tirer un mètre de laine, en fait, tu tires toute la pelote.
Et du coup, ça peut devenir décourageant, parce que d'un coup, tu as un espèce de truc,
un chantier énorme qui s'ouvre devant toi et tu refermes le capot en disant,
« Bon, tu sais quoi, on va faire à l'ancienne, et puis ça va bien passer parce que ma modif, elle va me prendre une heure. »
Alors, souvent, ça demande du courage.
Travail sur du code legacy, c'est pas facile, ça demande du courage.
Mais c'est un peu notre métier, donc du coup, si on avait que des choses belles à faire et travailler sur du greenfield,
on ne ferait que des applications neuves.
Donc, moi, je suis quelqu'un qui j'aime travailler sur le code legacy,
parce que j'essaye de conserver la valeur métier et la valeur du produit,
celui du produit qui rapporte de l'argent, tout en essayant d'introduire du clean code et un design correct.
Et c'est là toute la difficulté et toute la beauté de notre métier aussi.
Oui, je suis complètement d'accord avec toi que se limiter sur du, comme tu dis, du greenfield,
c'est vachement limitant parce que finalement, le greenfield, d'abord, il n'y a pas beaucoup.
Si tu regardes à l'échelle des projets, donc des entreprises qui sont potentiellement des futurs employeurs.
Et puis, même si moi, je vois beaucoup de boîtes qui démarrent des projets de zéro
et n'ayant pas forcément les techniques ou la maîtrise,
à un moment donné, le greenfield se transforme vite en une espèce d'usine à gaz.
Big ball of mud.
Oui, c'est ça.
Du coup, j'aime bien ce que tu dis.
Il faut du courage pour s'y attaquer, il faut de l'envie.
Et ce n'est pas forcément moins noble, voire au contraire,
je trouve qu'il y a quelque chose d'assez puissant dans le fait d'être capable de continuer à livrer la valeur de l'application
tout en améliorant l'intérieur et en finalement en augmentant l'alongévité de l'actif.
C'est un peu comme si, tu vois, moi, j'ai, j'ai, j'ai,
j'ai vécu le contrôle technique de mon camping car, j'ai une pièce assez importante à changer.
Bah là, je suis obligé d'arrêter le camping car et je ne peux plus partir en vacances.
Bah nous, on est capable de changer la traverse qui supporte le moteur pendant qu'on roule et qu'on est en vacances.
Et je trouve qu'il y a de la, il faut, en fait, ce que tu décris, je trouve que c'est ce qu'il y a de plus difficile à faire.
C'est-à-dire faire du refactoring, enfin, travailler sur du code legacy en le faisant évoluer et en amenant du TDD.
Je crois que c'est parmi les trucs les plus difficiles à faire parce que ça sous-entend d'être capable de travailler sur du refacto
ce qui n'est déjà pas rapporté de tout le monde, de maîtriser ce qu'on fait, d'amener du TDD, d'amener des principes de design.
Et souvent, je vois des équipes qui se lancent là-dedans, qui se lancent dans le TDD sur du legacy.
Les gars, c'est les pires conditions pour, pour s'y mettre quoi.
C'est vrai que c'est assez difficile, mais après, je, il y a un autre truc, il y a un autre aspect qui est intéressant, qui est décrit dans le livre qui s'appelle Team Geek,
qui parle de, de, de, de, de, de code, enfin, de, de travail offensif et de travail défensif.
Alors travail offensif, c'est une nouvelle fonctionnalité, c'est, c'est les nouvelles interfaces, c'est la performance, c'est, c'est tout ce qui se voit en fait.
Et puis, il y a du travail défensif.
Le travail défensif, c'est maintenir un code, euh, maintenable, euh, euh, rajouter des tests, euh, rendre le code lisible.
Malheureusement, le code défensif n'est pas aussi valorisé, même si, euh, pour nous, artisans logiciels, on sait toute la valeur qu'il y a le code défensif.
Euh, mais c'est quelque chose qui n'est pas trop valorisé en fait.
Donc c'est pour ça aussi peut-être que les gens le, le, le font pas, euh, ça demande du courage, c'est pas trop valorisé, personne le voit en fait, ce qu'on fait.
Et du coup, les gens se disent bah pourquoi je fais ça et pourquoi je fais pas, euh, des belles procédures stockées qui améliorent 400 fois ma performance de ma requête.
Ça va tout de suite se voir donc euh, il y a aussi cet aspect qui fait que...
Ouais, valorisant pour la personne, pas, parce que, pas, parce que pas valoriser aussi, moi je connais peu d'entrepreneurs,
ou je fais beaucoup avec des clients entrepreneurs, beaucoup de start-up, les mecs ils veulent avant tout de la feature, hein.
Oui. Et euh, quelque part euh, euh, quelque part la qualité intrinsèque, ils peuvent être sensibles au discours, mais fondamentalement ils veulent de la feature.
Ah donc euh, c'est ça qui est valorisé surtout, tu vois.

Parce que finalement, un horizon de, un an, deux ans, euh, ça leur paraît loin, alors que nous, derrière chaque décision qu'on prend,
quand on arrive à un certain niveau de conscience, on sait le coup que ça va engendrer plus tard.
Et euh, les compromis, qu'est-ce qu'on va devoir payer pour ça, quoi.
Puis y a des amis sur Bordeaux, dont un qui dit la qualité d'aujourd'hui c'est la vélocité de demain.
C'est, c'est très vrai quand on, quand on travaille sur des, des projets qui durent un peu.
Pour des start-upers, entrepreneurs, euh, y a d'autres problèmes à, à pas démarrer correctement.
Mais souvent, oui, on voit, on voit ce des fois apparaître.
Hmm, yes. Bah écoute, je te propose que ce soit le mot de la fin.
Si les auditeurs veulent en savoir plus sur ce que tu fais, ton travail, ils peuvent venir où ?
Euh, bah sur mon GitHub.
GitHub.com, Guillaume Vincent.
Et voir le code que je fais tout. J'essaye de mettre tout le code euh, que je fais en open source.
Je pense qu'il y a pas, y a très peu de code que je fais qui n'est pas ouvert.
Euh, une autre forme de courage, en lequel on pourra parler dans un prochain épisode.
Tu me parlais notamment de l'escode qui était un gestionnaire de mot de passe.
L'espace, ouais.
L'espace.
Ça marche, c'est cool.
Bah écoute, merci Guillaume d'être venu.
Merci à toi de m'avoir invité.
Quant à toi, chers auditeurs, j'espère que tu as apprécié ce podcast.
Et si tu as envie toi aussi d'apprendre à gérer du code legacy, je t'invite vraiment à rejoindre la formation dans la maison des compagnons.
Comment éviter de transformer son application en plate de spaghetti.
Ou justement, on reprend les techniques de base qui permettent de reprendre en main du code legacy.
Et je te dis à demain.
Sous-titres réalisés par la communauté d'Amara.org