Technologies

Retour d’expérience : Travailler avec des vieilles technologies

Publié le : Auteur: Hervé SAINT RAYMOND Laisser un commentaire
technologies

Les nouvelles technologies d’aujourd’hui seront-elle dépassées demain ? C’est la réflexion qui ressort dans le cadre d’une mission récente. Le projet en C++ employait un certain nombre de librairies et ajouts qui n’ont pas été mis à jour depuis des années. Les choix technologiques à l’époque (le début des années 90) s’étaient tournés vers des solutions, soit en logiciel libre (GNU/linux, X server) soit propriétaires (ObjectStore par exemple). Un certain nombre de ces choix ont concerné des technologies qui n’ont pas été mises à jour depuis, pour lesquelles la documentation est rare ou inexistante.

En pratique

Le projet était l’étude de faisabilité d’une migration d’un logiciel en C++ d’une architecture 32bits à une architecture 64bits afin de doubler la précision des calculs en virgule flottante. Le code comprend plusieurs milliers de lignes de C++ générées par un logiciel commercial. Ce code implémente l’interface graphique du projet. Il s’appuie sur les librairies Motif, Xt et X. Si la librairie X est toujours utilisée communément, ce n’est pas le cas de Motif et Xt et le logiciel ayant servi à générer ce code n’est plus ni distribué, ni documenté.

Cette implémentation présente des avantages non négligeables, notamment pour la création de nouveaux écrans : un simple fichier de configuration permet à ce segment de code de générer une interface graphique à la volée. L’application présente de nombreux écrans, et est développée par plusieurs prestations successives, mais arrive à garder une unité graphique, un fonctionnement très cohérent d’un écran à l’autre.

Le problème : ces quelques fichiers de code n’ont jamais été prévus pour fonctionner dans une architecture 64bits et les champs d’entrée/sortie sont toujours alloués en 32bits. La librairie X fait son travail correctement et écrit les valeurs d’entrée sur 64bits, ce qui provoque diverses erreurs d’exécution. Par ailleurs, le code généré n’est pas fait pour être édité, il n’y a donc aucun commentaire, aucune convention de nommage des variables, aucune indentation, aucune structure visible.

Au final, il a été possible de corriger certaines erreurs à l’aide d’un débugger, et de récupérer quelques fonctionnalités. Il reste malgré tout toujours des régressions. Il a fallu conclure à une impossibilité de la migration.

Pour mener cette migration, la seule solution réelle est de remplacer ce code en gardant la même interface avec le logiciel, et en utilisant une librairie graphique (éventuellement différente si on considère que Motif/Xt est dépassé). Or, pour avoir le même niveau de fonctionnalités, il est nécessaire de faire des développements relativement longs et compliqués. La réalité financière du projet était en l’occurence un frein à la réalisation de ces travaux.

En conclusion

Un certain nombre de ces considérations ne s’appliquent pas aux nouvelles technologies, surtout d’un point de vue technique. Java est remarquablement indépendant de l’architecture sur laquelle il est exécuté en particulier. On ne rencontrera donc certainement pas les mêmes problèmes quand les projets d’aujourd’hui auront 30 ans. Se pose tout de même la question de la maintenabilité du code dans les divers frameworks qu’on utilise. Seront-ils maintenus sur le long terme ? Si non, sera-t-il possible d’en changer facilement ?