Api Platform Conférence 2024 : Comment se sortir du legacy ? par Smaine Milianni

CDans notre série d'articles dédiée à l'API Platform Conference 2024, nous revenons aujourd'hui sur la conférence de Smaine Milianni intitulée "Comment se sortir du Legacy". 
Smaine a commencé par définir le terme "legacy", souvent mal compris. Selon lui, un code legacy est un code ancien qui reste précieux pour l'entreprise, mais qui présente l'inconvénient de ne pas être accompagné de tests automatisés, rendant sa maintenance complexe.
Pour éviter de tomber dans ce piège, Smaine a partagé plusieurs bonnes pratiques, allant de l'intégration de tests automatisés à la mise en place de la "Clean Architecture", en passant par l'application des principes Solid, Kiss, et Dry.

Comment sortir du legacy ?

Présenté par Smaine Milianni

Smaine Milianni est Engineering Manager chez Yousign, avec une solide expérience chez Edenred, Sensiolabs, l’Élysée et Greenflex. 

×

Lors du deuxième jour de conférence, Smaine Milianni a animé un talk dont l’objectif était de nous présenter des solutions permettant de se sortir d’une base de code dite “legacy”.

Il a tout d’abord commencé sa présentation en définissant clairement ce qu'était du code Legacy selon lui, bien que chaque entreprise ait parfois sa propre définition : 

• C’est du code “vieux”
• C’est du code qui a encore de la valeur (sinon il aurait été retiré de la base)
• C’est du code sans test (donc difficilement maintenable)

Éviter le code Legacy

Une fois cette définition posée, Smaine nous a expliqué que le plus simple pour éviter le code legacy c'était bien évidemment de ne pas commencer à en faire. Il nous a alors listé quelques techniques pour nous aider à atteindre cet objectif :

• Mettre en place des tests automatisés
• Mettre en place de l’analyse statique
• Mettre en place des Code Review
• Rembourser la dette technique régulièrement
• Mettre en place les bonnes pratiques de “Clean Code”
• Mettre en place des Design pattern dès que possible
• Appliquer les principes Solid / Kiss / Dry autant que possible
• Mettre en place les bonnes pratiques “Clean Architecture”
• Appliquer la “Boys Scout Rule” : Laisser le code plus propre que ce que l’on a trouvé en arrivant

×

En complément, Smaine nous a également proposé une paire d’outils pour nous aiguiller dans la mise en place de toutes ces bonnes pratiques : 

• La commande “Composer outdated” qui liste les dépendances composées à mettre à jour
• Bot Renovate (IA) : Un Bot IA qui crée directement des PR pour updater vos dépendances

Sortir du code Legacy 

Malgré toutes ces bonnes pratiques, il arrive parfois que l’on se retrouve à devoir reprendre un projet qui est déjà constitué de code legacy.

×

Nous n’avons donc pas le choix que de l’en faire sortir autant que possible. Pour y arriver, Smaine nous a exposé 3 méthodologies visant à nous aider à atteindre cet objectif : 

La méthode MIKADO

• Découper le travail de refactoring en petites tâches
• Lister les prérequis du refactoring
• Expérimenter avec de petites modifications pour valider ce qui fonctionne et ce qui bloque le fonctionnement de l’application

Le golder master testing

• Faire un “snapshot” des résultats des fonctions legacy
• Comparer ce snapshot des résultats legacy avec les résultats aprés le refactoring : les deux résultats doivent être identiques

Smoke test 

• Identifier les tests critiques (Liés aux fonctionnalités ayant le plus de valeur)
• Ne jouer que les tests critiques afin d’itérer plus rapidement sur le refactoring

Conclusion

Restez connectés pour découvrir nos prochains articles sur l'événement !