5 Déc 2014

Code Legacy : How to

Dans la majeure partie des cas de reprises d’applications, l’ajout de nouvelles fonctionnalités peut vite devenir très compliqué : mauvais design, pas de respect du découpage en couches, pas/peu de tests unitaires, code mal écrit, mal documenté, pas explicite, etc.

Comment peut-on se faciliter la tâche face à ce genre de situations ?

Qu’est-ce qu’on appelle le “Legacy Code” ?

En théorie, cela correspond à du code qui n’est plus supporté par les systèmes qui l’utilisent (système d’exploitation, navigateurs, etc.) ou plus maintenu par les éditeurs.

Dans la pratique, on parle plutôt d’un code dont on a hérité et qui s’avère difficile à faire évoluer et à maintenir.  Il s’agit aussi d’un code qui ne comporte pas de tests ou ayant une couverture de code insuffisante.

 

Quelles stratégies à adopter ?

L’idée est de présenter quelques grands concepts qui vont permettre de sécuriser les développements à effectuer autour du Code Legacy pour ensuite l’améliorer.

 

  • Golden Master Testing (Approche de la boite noire)

L’approche de type Golden Master va permettre d’écrire des tests globaux de l’application sans forcément chercher à comprendre ce qui est fait à l’intérieur.

On assimile l’application à une boite noire qui prends des données en entrée et renvoie des données en sortie.

Black Box

Approche Boite Noire

L’objectif est de pouvoir écrire des tests qui vont permettre de nous assurer qu’en envoyant la donnée A en entrée de l’application, celle-ci renvoie le résultat B en retour. (Si vous ne connaissez pas à l’avance les résultats attendus en fonction des entrées, un peu de Debug est fort utile :-))

L’exécution de ces tests va vous permettre de refactoriser le code, d’ajouter de nouvelles fonctionnalités en vous assurant que vous n’avez pas cassé l’existant car les résultats attendus seront toujours les bons.

L’avantage avec cette façon de faire est que vous n’êtes pas obligés de comprendre le code de l’application dans le détail pour pouvoir vous attaquer à vos développements.

Le gros inconvénient est que cela ne vous garantit pas une exhaustivité de tests et donc pas forcément une couverture de code optimale.

 

  • Reverse Engineering

Le reverse engineering de l’application vise, à l’inverse de l’approche “black box”, à comprendre les moindres détails de l’algorithme afin d’en écrire les tests unitaires. L’objectif sera donc de couvrir tout le code où les modifications souhaitées auront des impacts pour éviter la régression.

En plus d’améliorer la couverture de code par les tests de l’application, l’autre intérêt est d’être sûr de ne causer aucune régression sur l’existant au fur et à mesure de la refactorisation en rejouant à chaque fois les tests unitaires.

Cette méthode peut cependant s’avérer être assez longue et fastidieuse à mettre en place notamment lorsque le code comporte beaucoup de cas à couvrir.

 

  • Concept de la Strangler Application

Lorsque vous devez apporter de nouvelles fonctionnalités à un existant, une des possibilités est de recourir au concept de la Strangler Application (Description en anglais ici : http://www.martinfowler.com/bliki/StranglerApplication.html).

Strangler Application

Strangler Application

L’approche est plus radicale que les deux précédentes car elle vise à “éradiquer” l’ancien code de l’application. Pour ce faire, il faut ajouter les nouvelles fonctionnalités en partant sur une base saine avec un code bien conçu, bien écrit et testé tout en migrant progressivement les anciennes sur la base des nouvelles.

Cette méthode ne peut cependant pas s’appliquer à toutes les applications et doit être mûrement réfléchie. Il faut bien veiller à ce que l’ancien code soit bien migré vers le nouveau sinon le risque est de se retrouver avec deux versions de code à maintenir en parallèle.

 

Exercice / Dojo

Un exercice simple que je peux conseiller pour vous exercer à travailler avec du Code Legacy  : Gilded Rose (https://github.com/AxaWebCenter/GildedRose).

Nous avons fait cet exercice lors d’un dojo au Webcenter et il s’avère intéressant pour pouvoir tester les différentes approches.

L’objectif de l’exercice est d’ajouter une fonctionnalité sur l’application Gilded Rose. On hérite d’un code incompréhensible au premier coup d’œil, il faut donc choisir une stratégie pour pouvoir ajouter cette fonctionnalité.

L’objectif par la suite est de refactoriser le code existant pour améliorer l’application.

Références

Si vous souhaitez aller un peu plus loin dans votre documentation sur le Code Legacy, je vous conseille les livres suivants :

  • “Working Effectively with Legacy Code” de Micheal C. Feathers
  • “Refactoring : Improving the Design of Existing Code” de Martin Fowler
  • “Coder proprement” de Robert C. Martin

 

Share