Actus

p.06 Côté livres...
p.08 Créez des présentations animées avec Python

Dossier : Code Legacy ...ou comment maintenir vos vieux codes encore en production

p.30 Introduction au dossier
p.32 Les défis de la maintenance logicielle
p.42 Recréer un ancien environnement à l’aide de Docker
p.56 Déploiements reproductibles dans le temps avec GNU Guix
p.66 Arithmétique sur divers systèmes embarqués aux ressources contraintes : les nombres à virgule fixe

Outils

p.90 Concevoir des tableaux en LaTeX

Développement

p.110 Introduction à l’écriture de tests avec Erlang/OTP

Dans le dossier de ce hors-série, nous allons voir un aspect de la maintenance logicielle qui consiste essentiellement à recréer un environnement dans lequel un programme obsolète pourra être exécuté. Mais un autre aspect de la maintenance de code est à garder en mémoire également bien que se situant en amont : la qualité du code !

Si un logiciel est écrit en respectant les bonnes pratiques du ou des langages employés (conventions de nommage par exemple), que la documentation technique a été correctement écrite et complétée au fur et à mesure de l’avancée du projet et que les principes architecturaux de base ont été respectés, la maintenance sera nécessairement beaucoup plus aisée. En effet, si on ne parle pas d’adapter un environnement pour y faire tourner un code, mais d’adapter plutôt celui-ci pour qu’il fonctionne sur un système moderne (ou pour un programme actuel sur les futurs systèmes), le fait de porter une attention particulière à la qualité et ne pas se contenter d’un « machin » qui tourne permet d’éviter de se retrouver dans le futur dans le cas de la boîte noire que personne n’ose toucher de peur de la casser.

Comme souvent en informatique tout est question de compromis : est-ce que j’accepte de perdre du temps maintenant pour hypothétiquement en gagner d’ici quelques années, voire sauver l’activité de l’entreprise si le domaine d’application du logiciel incriminé est critique ? Est-ce que l’on gagne vraiment du temps à bâcler le travail ? Réfléchir à une architecture propre, documenter, tester sont des activités chronophages. Certains développeurs ne vont qu’à l’essentiel (l’aspect paresseux de l’informaticien, mais dans la mauvaise appréciation du terme). D’un autre côté, ce ne sont pas toujours les développeurs qui sont à blâmer, encore faut-il que les chefs d’équipes et dirigeants soient conscients qu’il faut du temps pour réaliser du bon travail !

Une fois que les contraintes de qualité ont été prises en compte, le portage du code nécessitera alors un travail minime et bien entendu la recréation d’un environnement adéquat au bon fonctionnement du logiciel sera toujours possible, et pour cela vous n’avez qu’à lire le dossier de ce hors-série...

Tristan Colombo