[Agile France 2013] Code Legacy : faire évoluer ou ré-écrire ?

logo Les 23 et 24 mai a eu lieu l’Agile France 2013, dans le superbe cadre du Chalet Jaune à Vincennes. Ça a été pour moi l’occasion de participer à la conférence “Code Legacy : faire évoluer ou réécrire ?” de Cyrille Martraire. Le thème de la réécriture de code est un vaste sujet, thème de nombreux ouvrages de par sa complexité et son actualité puisque de nombreux projets de développement se base sur du code existant.

Qu’est-ce que le code legacy ?

Aujourd’hui, de plus en plus de code sur lequel nous sommes amenés à travailler est du code legacy, mais qu’est-ce qu’on entend par là ?

A l’origine, le code legacy était du code source non supporté qui se trouvait dans du nouveau code afin d’assurer le maintient d’anciennes fonctionnalités. Un code peut également devenir legacy lors d’un changement de plateforme empêchant le fonctionnement dudit code sans changement, parfois important.

Michael Feathers, auteur du livre “Working Effectively with Legacy Code”, a redéfini le code legacy comme du code sans test, ce qui le rendra difficile d’utilisation à l’avenir, notamment vis-à-vis des régressions.

Sachant que les développeurs sont de plus en plus souvent amenés à travailler avec du code legacy, une question importante se pose : doit-on faire évoluer le code ou le réécrire ?

Evoluer ou Réécrire ?

Le besoin vient du fait qu’on veut quelque chose de nouveau et parfois vraiment différent au sein de l’application, mais qu’on se retrouve bloqué par les limitations du code hérité. Bien entendu, le premier réflexe sera de réécrire entièrement le code afin de dépasser cet obstacle, réflexe qui pourrait ne pas être le bon…

Pourquoi maintenons-nous le code legacy ?

0131177052.01.S001.LXXXXXXX

Bien qu’il n’y ait pas de test et que la dette technique soit importante, ce code représente des fonctionnalités de l’application et donc une valeur ajoutée pour l’entreprise. Or, réécrire ce code revient à jeter du code fonctionnel, ce qui est un gâchis, et ensuite on introduit le risque que la même fonctionnalité, nouvellement implémentée, ne fonctionne pas ou pas de la même façon.

“Un code mal écrit qui fonctionne bien et qu’on ne change pas est quelque chose de normal.”

Comme on peut s’en douter, sans la présence de tests,  il sera long et difficile de tester du code legacy. Il est donc vital de préalablement évaluer le coût du changement avant de prendre une décision. Lorsque nous voulons de nouvelles fonctionnalités, il est nécessaire d’introduire des changements. L’approche “Just Do It”, qui est celle employée par de nombreux développeurs et qui consiste à juste faire ces modifications rapidement et localement, peut s’avérer au contraire très longue, car la non-régression pourra obliger le développeur à répercuter des changements encore et encore un peu partout dans l’application.

Comment réécrire le code ?

Réécrire le code doit être différenciant pour le business, sans quoi il n’y a pas d’intérêt et on pourra simplement acheter une solution tierce.  Cependant, il faudra faire attention à ne pas entrer dans un cercle vicieux où, dans le but de réécrire une partie du code, on en change une autre, puis une autre, et ainsi de suite sans fin. Il est nécessaire de ne changer que le minimum absolu.

Stratégie

Afin de réécrire une partie de l’application, il faudra tout d’abord découvrir cette application, sa composition, et visualiser ce qu’elle fait.

Intégration

Martin Fowler, grand nom de l’agilité, introduit la notion d’Asset Capture, qu’il définit comme “une stratégie pour développer une Strangler Application”. Il est possible de voir un grand nombre d’applications comme un ensemble de fonctionnalités, plus ou moins indépendantes mais qui travaillent ensemble afin d’obtenir le produit voulu.  Visualiser ce que fait notre application nous permet de mettre en exergue ces fonctionnalités, ou assets, et ainsi permettre la modification unitaire de ces fonctionnalités.

Le concept de Strangler Application est en fait une analogie entre l’intégration avec du code legacy et une certaine espèce de liane que Fowler a observé en Australie et qui a la particularité de grandir le long d’arbres au point de les étouffer. L’idée est de développer du code nouveau autour du code legacy, et d’activer ou de désactiver ce code à l’aide d’interrupteurs. Ces interrupteurs, de simples if au niveau du code, permettront ainsi le retour aux fonctionnalités d’origine, si le besoin apparaissait, réduisant ainsi les risques vis-à-vis de l’application.

Quels outils ?

On se basera sur une méthodologie de type TDD, BDD ou encore DDD. Cyrille recommande d’investir dans le Domain Driven Design afin de créer un « bubble context », un environnement clos au sein du code où aura lieu la réécriture, à l’aide d’une couche anti-corruption (ACL) qui est en fait un ensemble d’adapteurs dans le code.

Frontières et limites

Cyrille nous a évoqué les bonnes pratiques  de la réécriture de code legacy via trois maximes :

  • « Un seul chantier à la fois » : ne tentez pas de réécrire toute l’application d’un coup ou à plusieurs endroits à la fois ;
  • « A Rome, faisons comme les romains » : lorsque vous réécrivez du code, tentez de maintenir le style et la logique du code précédant, afin d’assurer la cohérence du code ;
  • « Le code te dit tout » : bien que souvent avec le code legacy il n’y a ni tests, ni documentation, le code devrait fournir les informations nécessaires à sa réécriture.

Main dans la main

Une réécriture est généralement voulue parce qu’un besoin métier a changé. On va donc injecter une connaissance nouvelle dans le code et pour cela il est nécessaire d’avoir une analyse métier importante. Comme nous l’avons vu précédemment, une vision de l’ancien et du nouveau flux de l’application facilitera grandement l’intégration tout en réduisant les risques.

Que faire avec le code ancien ?

icecube Le problème avec le principe de la Strangler Application est qu’on a du code double, le legacy et le nouveau, faisant la même chose. On va geler le code legacy, c’est-à-dire qu’on ne le fera plus évoluer et qu’on se concentrera uniquement sur le nouveau.

Conclusion

Cette session animée par Cyrille Martraire a été très instructive et vraiment bien faite. Le thème du code legacy est une problématique récurrente et parfois difficile à traiter, sachant l’aversion qu’a la majorité des développeurs pour reprendre du code ancien et le réflexe de jeter ce code pour le remplacer sans autre forme de procès.

Pour aller plus loin

Nombre de vue : 585

COMMENTAIRES 3 commentaires

  1. […] Retrouvez l’article complet sur http://blog.soat.fr/2013/05/agile-france-2013-code-legacy-faire-evoluer-ou-reecrire/ […]

  2. […] vous la connaissez, on en parle régulièrement sur le blog : qu’il s’agisse de refactoring ou de méthodologie d’écriture de code, vous avez tous les outils en main […]

AJOUTER UN COMMENTAIRE