Jusqu’à l’AFUP Day 2023, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Comment refondre un legacy sans cris et sans larmes - Retour d'expérience et bonnes pratiques Un legacy de plusieurs années fait toujours peur : du vieux code PHP 4, pas de template, pas de POO, beaucoup de mauvaises pratiques... Alors quand on décide de refondre tout ça, c'est la panique. Dans cette conférence, je vous propose de partager le retour d'expérience d'une refonte d'un intranet BtoB. Outillage, bonnes pratiques, architecture logicielle, monitoring, documentation, et formation. Je vous explique tout ce qui nous a permis de réaliser une refonte sans cris et sans larmes.

C.P.E. 12/05/2023 14:45-15:05

Citons Matthieu Napoli lors de sa conférence « L’architecture progressive » au Forum PHP 2019 : « Du code legacy, c’est un projet qui a réussi ». Est-ce tout le temps le cas et qu’en est-il de ton projet ?

Je suis plutôt d’accord avec Matthieu, en tout cas sur l’aspect racoleur de la citation 😛. Plus sérieusement, si on se pose la question de vouloir refondre du legacy, c’est souvent parce que le code « juste marche », mais qu’on n’est pas serein pour l’avenir.

À quoi bon revoir du code qui n’apporte rien ? La beauté du code pour la beauté du code n’a rarement pas sa place dans le business.

Concernant mon projet, on est sur le cas d’école d’une application codée « à l’ancienne ». C’est-à-dire, pas de POO, tout en procédurale, pas de MVC donc, et ton fichier PHP, il fait du contrôle, du domaine et de la vue. Et pourtant cette application, elle fait gagner des millions et n’est maintenue que par une personne qui n’a jamais bougé et qui ne connaît que son code.

Sur le papier, tout roule, sauf que le jour où ce développeur part pour X raisons, l’application, elle est bloquée. Et je ne parle même pas des problèmes de maintenance, d’évolution, de régression etc …

Donc, non, ce serait illusoire de penser qu’une application legacy peut rester comme telle sans jamais devoir ouvrir le capot pour changer 2/3 pièces, si ce n’est pas carrément le moteur, car on a trop attendu.

Ça y est, ce projet legacy va être revu. Mais avant de tout casser, quelles autres solutions que la refonte se proposent à nous et comment décide-t-on de ce qui va être réalisé ?

Alors, je n’ai jamais dit qu’il fallait tout refondre d’un seul coup. Je ne préconiserai jamais de faire ça : comme je l’ai dit, si on se pose la question de revoir un legacy, c’est qu’on parle d’un code qui tourne et qui fonctionne. Tout refondre sans stratégie serait aller droit dans le mur.

Je ne pourrais pas donner une recette miracle, ça dépend du projet et des objectifs de l’équipe qui tient le projet. Pour mon cas, la stratégie était de refondre petit à petit sur un Symfony à côté de l’application legacy avec un pont entre les deux écosystèmes, mais parce qu’on ne pouvait pratiquement rien tirer du code existant, beaucoup trop vieux.

Pour des projets plus récents, on peut déjà regarder la complexité du projet, les parties critiques, les gains potentiels etc … Puis arbitrer sur l’ajout de modèle de conception ou d’implémentation d’architecture qui permettrait de résoudre des problèmes ciblés. Sauf exception, il est assez rare de tomber sur des projets où tout est bon à jeter.

Dans tous les cas, la première étape, c’est de se mettre autour d’une table avec des gens compétents (si vous cherchez, contactez-nous chez Akawaka 😉), regarder le projet, en tirer les forces et faiblesses et définir une stratégie, que cela soit une refonte progressive ou juste implémenter des modèles de conceptions / des points d’architecture.

Et pour éviter de « tout casser », justement, j’en parle dans ma conférence, je donne des conseils et des moyens de mettre des filets de sécurité pour éviter les ennuis.

Tu as lancé CatAsAservice qui est un projet plutôt ancien. Le considères-tu comme du legacy et comment le gères-tu ?

Touché ! Cataas c’est un assemblage de petits bouts de trucs que j’ai faits, tranquille, dans ma chambre. J’ai dû commencer le projet automne 2015 avec une v1 un an plus tard. À l’époque, j’apprenais les API REST et j’aime bien les chats, ensuite, j’ai voulu faire mon propre framework JavaScript, puis j’ai joué avec les WebSocket etc …

Cataas c’est un assemblage de technos sur lesquelles je voulais me former, sauf qu’aujourd’hui, c’est un demi-million d’appels API par jour, et deux attaques DDOS par semaine, c’est beau qu’il soit toujours en ligne (bon, je dois le relancer quelques fois).

Donc oui, c’est du legacy, et j’aimerais beaucoup revoir la base, virer les trucs inutiles, revoir l’infrastructure etc … Ce n’est pas un gros projet, finalement au fil du temps, j’ai enlevé des fonctionnalités pour me concentrer sur l’essentiel. Refondre d’un coup ne prendrait pas tant de temps, mais pas demain : demain, j’ai mon autre side-project à finir 😀

Une conférence présentée par

Kevin BALICOT

Brasseur codeur, ~10 ans d'expérience, Backend, Frontend, et un peu Ops à travers PHP, JavaScript, Docker, Apache etc ... Kévin est passé par plusieurs boites, telles que Wanimo, PSIH, Dedi Agency et aujourd'hui Akawaka en tant que Lead Développeur. Il a fait de la vacation pendant 4 ans au DUT et IUT de Lyon 1 - Bourg en Bresse sur de la programmation, de l'admin système ou bien de la sécurité. Il s'est aussi essayé à la rédaction d'article technique sur son blog (https://boutdecode.fr/) et il s'ouvre actuellement sur l'architecture logicielle via le DDD, l'Hexa, clean code, CQRS, ADR ... Enfin, il est porte-étendard du mouvement lolcats via la création de http://cataas.com

Autres intervenants