[BACK FROM NEWCRAFTS] LA GESTION DU CODE LEGACY CHEZ YOUNITED CREDIT

Lors de la dernière Newcraft 2018, j’ai beaucoup apprécié la session de clôture présenté par Dylan Beattie.
Elle avait pour sujet le code legacy, vaste sujet de discussion dans le domaine du développement.
Si tout développeur à un jour ou l’autre été confronté à ce que l’on appelle du code legacy, sa définition peut varier d’une personne à l’autre. Mais au final cela conduit souvent au débat suivant : faut-il réécrire ce code ou essayer de le maintenir ?

Lors de ce talk, Dylan nous partage son expérience et ses astuces pour changer notre perception à propos du code legacy et ainsi pouvoir exploiter son potentiel.

Sur ce sujet, Younited ne fait pas exception et possède des applications considérées comme legacy. L’objectif de cet article est de vous présenter notre progression au fil des années sur la gestion de ce sujet épineux.

La genèse du code legacy

Avant de commencer, petite précision sur ce que l’on peut considérer comme legacy. Pour moi c’est du code qui a été écrit par des développeurs qui ne sont plus là pour vous expliquer le pourquoi. Cela peut aussi être du code qui accuse son âge. Cela peut être tout simplement du code qui a été écrit rapidement, sans test, ni documentation et qui n’est plus modifié par la suite avant un long moment.

La progression au fil des années

Quand je suis arrivé chez Prêt d’Union en 2015 (donc avant le renommage en Younited Credit), j’ai pu découvrir les applications qui faisaient fonctionner l’entreprise. Ces applications étaient regroupés dans une solution Visual Studio contenant les différentes briques nécessaires. Applications qui constituaient ce que l’on peut appeler un monolithique.

A l’époque, une de mes missions était d’aider l’équipe en place à améliorer ces pratiques de développements (tests, intégration continue, gestion d’erreurs et logs) ainsi que de préparer à l’internationalisation de l’activité.

Acte 1 : l’ignorance

Suite au besoin métier d’internationaliser l’activité, nous avons dû analyser l’existant afin de déterminer si l’existant pouvait être facilement modifiable pour gérer d’autres pays. Comme vous pouvez surement vous en douter il a été rapidement déterminé que cela n’était pas le cas.

Il a donc dû fallu décider comment procéder : investir dans les modifications nécessaires pour internationaliser l’existant ou partir sur de nouvelles bases.

La décision a été prise de partir vers un nouveau système, l’Italie est donc sortie 6 mois plus tard sur un système flambant neuf de microservices qui ne couvrait qu’un périmètre très limité comparé à ce qui se faisait en France. Pour le moment, tout va bien dans le meilleur des mondes.

Acte 2 : la révélation

Jusqu’ici nous avions concentré notre énergie sur la sortie de ce nouveau pays. Et les applications gérant la France — le legacy, donc — avaient été évitées ou ignorées par la plupart des nouveaux développeurs. Malheureusement, en raison de la croissance de l’activité, ces applications ont commencé à rencontrer des incidents de plus en plus fréquents, incidents qui commençaient à avoir un impact non-négligeable et ne pouvaient plus être ignorés.

En plus de cela, nous nous sommes rapidement rendus compte que pour gérer l’Italie et plus particulièrement la fin du parcours métier correspondant à la gestion financière des crédits, nous allions avoir besoin du legacy. Cette partie était toujours dépendante de la base de données historique et nous n’avions pas eu l’occasion de remplacer les processus concernés.

On peut essayer d’ignorer et de contourner le code legacy mais il se rappelle toujours à vous à un moment donné. Comme par exemple, l’application ou le batch oublié sur le serveur historique qui se rappelle à votre bon souvenir quand vous pensez avoir tout prévu dans votre nouveau système flambant neuf, et là c’est le drame…

Pas le choix, vous devez prendre en compte le legacy.

Acte 3 : l’âge de la raison

Maintenant que nous avons bien pris conscience que ce legacy était là pour durer encore longtemps, il faut donc maintenant mettre en place une stratégie pour accompagner cette réalité.

Cette stratégie va déprendre des contraintes que ce legacy impose. Chez Younited, il s’agit principalement de la base de données centrale qui est encore utilisée par certains pans du métier. Il est donc indispensable que les données de celle-ci soient toujours en phase avec les nouvelles briques du SI.

Pour assurer cette cohérence, plusieurs stratégies ont été utilisées :

• La synchronisation de données
• L’identification et isolation des liens avec la base de données legacy

Dans la mise en place de ces stratégies, il est indispensable d’éviter autant que possible d’ajouter des dépendances directes entre la base de données legacy et les nouveaux microservices.

Stratégie de synchronisation

Afin de garder une cohérence entre les données de l’ancien et du nouveau système, nous avons dû mettre en place des mécanismes de synchronisation pour certaines données. Cette synchronisation est liée à des événements qui sont déclenchés par le nouveau et l’ancien système (exemple : contrat mis à jour). Dans certains cas très précis, il peut s’agir d’appel synchrone.

Ce sont les référentiels de données du nouveau SI qui font foi. Nous sommes dans une relation master/slave mais avec une synchronisation bidirectionnelle.

Cette logique de synchronisation pourra disparaitre au fur et à mesure que les nouvelles briques du SI implémenteront les fonctionnalités de l’ancien SI.

Identification et isolation des liens Legacy / Nouveau SI

Certains microservices avaient besoin d’accéder aux données du legacy, que ce soit parce qu’une fonctionnalité n’existe pas encore dans le nouveau système ou soit parce que la donnée nécessaire n’est pas encore gérée dans le nouveau système.

Pour ce genre de cas, nous avons mis en place une API qui agit comme une couche anti-corruption entre la base de données legacy et le nouveau SI.

Les objectifs sont les suivants :

• Eviter les connexions SQL directes entre les microservices et la base de données legacy. Cette contrainte est en partie dû à l’infrastructure IaaS utilisée pour le legacy par rapport à notre infrastructure PaaS du nouveau SI.
• Offrir une abstraction de la base de données et des concepts legacy pour éviter de faire transpirer des concepts legacy dans les nouvelles applications. Exemple : les identifiants de contrats utilisés ne sont pas les mêmes dans l’ancien et le nouveau SI. On ne veut donc pas polluer le nouveau SI avec des références à ces identifiants legacy et l’ACL a pour responsabilité de gérer ce mapping.
• Permettre de centraliser et d’identifier plus facilement quelle domaine utilise quelle données dans l’ancienne base afin de pouvoir migrer au fur et à mesure vers le nouveau SI. Cela nous sert de kill list.

Planification de la migration vers le nouveau SI

Une fois que nous avons mis en place ces différents chantiers, nous y voyons déjà plus clair et avons amélioré notre maitrise de ce legacy. Rien n’est pourtant gagné, il ne faut surtout pas oublier de planifier, sur plus ou moins long terme, le décommissionnement de ces briques de synchronisation et d’isolement du legacy. Dans le cas contraire, ces briques pourraient également devenir une entrave à l’évolution et la maintenance du SI.

Acte 4 : la patience

Entre temps, nous avons ouvert 2 nouveaux pays et le nouveau système d’information est beaucoup plus étoffé et internationalisé qui ne l’a jamais été. Malgré cela il nous reste encore beaucoup de travail. Le code legacy historique est toujours présent, une partie non négligeable a été remplacée et le reste est sous contrôle. Nous avons même créé une équipe dont une des missions principales est le suivi et décommissionnement des vieilles applications dès que cela est possible. Cela permet d’intégrer cette démarche à des projets métiers plus ou moins transverses.

On s’est également rendu compte que du code écrit pour l’internationalisation pourrait rapidement être considéré comme legacy si on ne luit accordait pas suffisamment d’attention : l’obsession du time to market peut avoir des effets pervers. Il ne faut donc jamais baisser la garde au risque de retomber dans les même travers.

Conclusion

Chaque entreprise et métier ont leurs spécificités, il n’y a pas de recette magique pour gérer le code legacy car tout dépends du contexte.

Nous aurions surement gagné beaucoup de temps si nous avions vu ce talk quelques années auparavant. Je vous invite donc vivement à regarder la vidéo, elle est vraiment enrichissante pour expliquer ce sujet tant redouté par les développeurs du monde entier.

Et on finira sur une citation de notre CTO Stéphane Alizon : «le legacy ce n’est pas sale». Il a dû marteler ce slogan pendant de long mois avant que les développeurs acceptent finalement d’adopter ce legacy et de le dépecer à petit à petit.