Systèmes existants : refactoring et/ou legacy : des approches combinées

C’est l’une des questions centrales face à un système informatique complexe que l’on veut faire basculer sur une nouvelle plateforme : faut-il conserver le maximum de code hérité (legacy) ou reprendre certains éléments pour les simplifier (refactoring) ? Arbitrons cette questions à travers un cas pratique qui illustre comment combiner ces approches.

Qu’appelle-t-on « legacy »

Comme la presse en fournit régulièrement des exemples savoureux, l’obsolescence en informatique est parfois une notion toute relative. L’un des plus célèbres avions longs-courriers du monde, le Boeing 747, est régulièrement mis à jour au moyen d’une technologie de stockage de données qui a fait ses preuves, la disquette. Récemment, la Deutsche Bahn, compagnie ferroviaire allemande, a fait très sérieusement figurer Windows 3.11 dans les prérequis techniques d’une offre d’emploi. Le système d’exploitation, sorti au début des années 1990, tourne toujours sur certains postes métier.

Il faut dire que dans certains environnements critiques, on ne remplace jamais ce qui fonctionne. Une règle qui explique que cohabitent dans bien des systèmes des logiciels ou des composants dits « legacy », c’est-à-dire hérités d’anciennes plateformes, et des éléments de code plus contemporains.

Dans un système complexe, des éléments « legacy » peuvent poser des problèmes majeurs. Ils sont d’une part très durs à maintenir, souvent liés à des dépendances opaques, et peuvent représenter une importante dette technique, c’est-à-dire que le travail pour le remplacer sera plus important que s’ils avaient été régulièrement mis à jour ou optimisés.

Face à un code legacy, il est possible d’avoir recours à des outils d’analyses statiques (comme des linters) pour évaluer et documenter la pertinence du code et en comprendre la logique. Dans certaines situations, et afin qu’un composant ou qu’un logiciel puisse fonctionner de manière optimisée dans un nouvel environnement, on fait appel au refactoring.

Le refactoring, une étape nécessaire 

Face à un système hérité, le vertige est parfois de mise. Des milliers de lignes de code, parfois dans un langage obsolète, ou des frameworks jamais mis un jour, des ajouts ponctuels non documentés, des fonctionnalités fiables mais dont on ignore les dépendances et les parties du code efficaces… L’idée maîtresse du refactoring consiste à se servir de différents outils pour analyser le code dans le détail, puis le simplifier en se débarrassant des parties « mortes ».

Plus souple que le rewriting, et aussi moins coûteux, le refactoring s’impose comme une philosophie : c’est une manière de coder qui suscite l’intelligence collective, use de l’amélioration continue pour transformer une application legacy en un ensemble maintenable et modulable, et impose une rédaction intelligible aux développeurs.

Cas pratique : le refactoring dans un contexte de système ferroviaire

L’informatisation de la circulation ferroviaire, de la cabine du mécanicien aux postes d’aiguillage, a accéléré au cours des années 1990-2000, de manière à ce que l’ensemble des dispositifs métier dépendent à la fois d’un hardware électronique et d’un software dédié. Aujourd’hui, un réseau national voit cohabiter des applications mises à jour avec des systèmes opérationnels datant d’il y a plus de trente ans, sur des systèmes spécifiques.

Pour ce cas pratique, on peut appliquer ce que l’informatique ferroviaire réalise actuellement dans le cadre de différents projets : examiner l’ensemble de ses logiciels en créant un jumeau numérique à grande échelle de son réseau, en y incluant tous les sous-systèmes métier, de manière à reproduire, par simulation, la circulation des trains et l’ensemble des logiques connexes qu’elle sous-tend (notamment l’aiguillage, la maintenance, la réponse aux intempéries/crises).

De cette manière, une équipe de développement peut faire migrer l’ensemble des codes hérités et fonctionnels, de manière à les tester non pas dans une situation réelle qui peut avoir un impact sur la circulation et le trafic, mais dans une version simulée, où les refactorings éventuels n’entraînent pas de conséquence négative en cas d’erreur.

• Première phase : migration et test 

Pour créer un jumeau numérique, un ensemble de logiciels doit être porté sur cette plateforme entièrement simulée. Par exemple, la communication entre rail et train est assurée par un système critique codé en ADA, pour les TGV français. Ces systèmes électroniques cohabitent avec des postes d’aiguillage informatisés de « troisième génération », utilisant un cloud fermé et des dispositifs IoT.

Sur d’anciens codes hérités, le jumeau numérique doit permettre de réaliser des tests unitaires et des tests d’intégration. Le but de l’opération ? Analyser in situ comment un système fonctionne et dans quelle mesure ses fonctionnalités peuvent être rédigées plus simplement, en anticipant sur des demandes futures : dans le domaine ferroviaire, les systèmes embarqués sur les voies électrifiées font l’objet d’une harmonisation européenne qui doit unifier des machines répondant actuellement à 26 normes nationales différentes, correspondant à autant de logiciels.

• Deuxième phase : analyse et définition du refactoring 

Pour un programme donné, l’analyse post-test doit permettre d’analyser comment le code assure 100 % des fonctionnalités métier. Pour ce faire, une des méthodes les plus populaires se nomme Mikado : comme dans le jeu du même nom, on cherche à retirer des sections sans affecter l’objectif du logiciel. Il s’agit donc d’explorer le code pour en tracer les principales dépendances, voir comment les différentes sections et fonctions sont enchevêtrées les unes aux autres, puis de mettre en place un plan pour simplifier ou carrément supprimer des portions de code présentant des passages peu clairs, redondants ou inutiles. Le fait de pouvoir tester en condition réelle sur le jumeau numérique chaque modification apporte un plus significatif.

• Troisième phase : refactoring 

Le refactoring à proprement parler s’appuie sur une logique d’adaptation du code à un nouvel environnement et de correction/suppression, par exemple, pour éliminer les redondances. Tout au long de la procédure, et selon le langage employé, le développeur peut s’appuyer sur des outils d’analyse statique, mais aussi des frameworks avec automatisation du code et une solution de gestion de version, pour mettre en place, par exemple, des pipelines CI/CD à destination de l’outil de déploiement final.

Aujourd’hui, dans de nombreuses entreprises, la gestion du code hérité et des projets anciens toujours opérationnels fait partie du quotidien des développeurs. Le refactoring, qui applique aussi bien une philosophie nouvelle qu’un ensemble d’outils puissants, figure parmi les solutions de choix à connaître !

Chez agap2IT, nous accompagnons les entreprises dans la gestion et l’optimisation de leur patrimoine logiciel. La maintenance du code hérité et des projets anciens toujours en production est un défi quotidien pour les développeurs. C’est pourquoi nous mettons à disposition notre expertise et nos solutions de refactoring, alliant une approche moderne et des outils performants, pour assurer la pérennité et l’évolutivité de vos applications.

👉 Nous rejoindre.