Julien Carnelos Blog – Archives

Les projets de maintenance sur de l’existant ou le « legacy code » sont fréquents.

Le « legacy code » possède une définition simple : « C’est du code si vieux/mal fait qu’on a peur d’y toucher« . Malheureusement, il faut tout de même y toucher à un moment pour le maintenir ou ajouter des évolutions (et combattre le statu-quo!). C’est à ce moment là que quelques bonnes pratiques peuvent sauver le développeur de la démence…

Je vous recommande la lecture d’un excellent article de Jeremy Miller, Removing the « Legacy » from your Code qui décrit sa stratégie générale.

Les points essentiels que j’ai retenu et déjà appliqué :

1. Gérer ses ressources : Inutile de partir bille en tête dans une refonte totale du projet. Cela sera sûrement une perte de temps. On ne touche aux morceaux de l’appli que lorsque l’on veut ajouter une valeur métier. A ce moment là, il faudra en profiter pour améliorer le design de l’application.

2. Automatiser le build : C’est souvent un point critique sur les anciennes applications. Une procédure de compilation / déploiement en 15 étapes à la main est source d’erreur et de problèmes de configuration. C’est ici que les outils de build comme ANT/NANT (Maven, Rake,…) peuvent être utilisés à bon escient.

3.  Avoir une vision globale de où l’on souhaite aller : On peut mettre en place au sein de l’équipe une vision du projet à long terme. Par exemple, se fixer comme objectif de remplacer l’ancienne couche DAO par le framework ORM Hibernate/NHibernate. Un wiki collaboratif interne conviendra très bien à ce genre d’informations.

4. Visible du management : Dans l’idéal, il faut que l’idée de cette amélioration du projet par à coups et en douceur soit acceptée par la direction. Avec son support, les modifications majeures seront plus faciles à porter. Par expérience, malheureusement ça sera rarement le cas. Dans ce cas il suffit d’adopter la technique du sous-marin : J’intègre dans mon chiffrage le temps d’effectuer les mises à jour techniques nécessaires. Attention, cette technique doit avoir l’aval de l’équipe technique sous peine de se retrouver isolé…

5. Interdiction d’abîmer le code : Le code source du projet est déjà suffisament ancien, toute modification de celui-ci doit respecter la qualité attendue. Aucune verrue supplémentaire ne doit être tolérée.