Réécriture ou Refactoring du code legacy : Trouvez le bon équilibre

Dans le contexte professionnel actuel, les systèmes comportant un legacy PHP se retrouvent partout. Ces applications, souvent développées il y a plus de dix ans, continuent de faire tourner des processus métier critiques malgré un code vieillissant. Face à ce type d'enjeux, une question cruciale se pose souvent pour les décideurs techniques : réécrire le code en intégralité ou l'améliorer de façon progressive ?

Vous pouvez également consulter notre livre blanc sur la migration d'un legacy PHP vers un framework moderne comme Symfony.

La tentation de tout réécrire

L’approche "tout réécrire" est séduisante à bien des égards. Repartir de zéro permet de se libérer de la dette technique et de modèles de conception obsolètes. Un nouveau projet peut bénéficier dès le départ des avantages des frameworks modernes et des meilleures pratiques. Les équipes de développement préfèrent souvent construire du neuf plutôt que maintenir un legacy. Et sur le plan technique, une réécriture promet des solutions élégantes, sans avoir de compromis à faire avec un code hérité du passé.

Quand on découvre pour la première fois une application PHP legacy – avec du HTML mélangé au PHP, des variables globales et aucun test – la première réaction d'un développeur est souvent de dire : "Il faut tout réécrire".

La réalité d'une réécriture

Avec l’expérience, viennent des leçons importantes. Une réécriture prend presque toujours plus de temps que prévu, parfois même deux à trois fois plus. Des aspects essentiels de la logique métier et des besoins peu répandus peuvent être enfouis dans l’ancien code et facilement oubliés. Les utilisateurs s'attendent à ce que toutes les fonctionnalités existantes soient toujours présentes, y compris celles qu’on croyait inutilisées. Le nouveau code introduit aussi ses propres bugs, parfois en créant de nouveaux problèmes qui remplacent les anciens. Pendant les périodes de transition, l'exploitation de deux systèmes en parallèle peut introduire de la complexité et des problèmes de synchronisation souvent insurmontables.

Trouver le juste milieu : le refactoring stratégique

Une approche plus équilibrée de cette question consiste à conserver ce qui fonctionne et améliorer ce qui ne fonctionne pas.

Les avantages du refactoring progressif

Grâce à une amélioration incrémentale, l'application reste opérationnelle tout au long du processus. Les changements peuvent être introduits progressivement, avec des ajustements en cours de route. Cette méthode permet de mieux comprendre la logique métier en travaillant sur le code existant. En plus, les ressources peuvent être concentrées sur les sujets critiques, au lieu de tout reconstruire en une seule fois. Et pour couronner le tout, les parties prenantes voient des améliorations continues au lieu d’attendre une livraison finale qui peut arriver ou non dans les délais.

Des conseils concrets pour un refactoring stratégique

1. Commencez par mettre en place un système de versioning (si ce n’est pas déjà fait).

2. Introduisez des tests automatisés pour valider le comportement actuel avant toute modification.

3. Extrayez peu à peu la logique métier de la couche de présentation.

4. Mettez à jour la version de PHP pour bénéficier des améliorations de performance et de sécurité.

5. Utilisez des patterns comme l’injection de dépendances ou une architecture MVC là où cela apporte une réelle valeur.

Docker peut aussi aider à assurer la cohérence entre les environnements de développement et de production.

Trouver le bon équilibre

La bonne stratégie dépend de plusieurs facteurs. Il faut vous poser les bonnes questions. Pêle-mêle, en voici quelques unes.

• A quel point est il important d'assurer le fonctionnement en continu du système ?

• Avez-vous une équipe capable de gérer à la fois la maintenance et les améliorations ?

• Quelle est la complexité du code actuel ?

• Y a-t-il des échéances ou événements métier à prendre en compte ?

Quand une réécriture complète a du sens

Même si le refactoring est souvent préférable, une réécriture complète peut se justifier dans plusieurs cas de figure. Tout d'abord, si la stack technologique est totalement obsolète (par exemple PHP 5.3 ou une version antérieure). Egalement, si les besoins métier ont profondément évolué ou si l’application doit servir à des usages très différents. Enfin, si l’architecture actuelle ne permet tout simplement pas d’implémenter des fonctionnalités essentielles, réécrire le code en intégralité peut s'avérer nécessaire.

Conclusion

La meilleure approche pour gérer le legacy PHP doit être pragmatique. Il s’agit de faire un choix en fonction de la stratégie : refactoriser le code, réécrire en intégralité ou le laisser tel quel – pour l’instant.

Et n’oubliez pas : malgré leurs défauts, ces applications fonctionnent depuis des années et gèrent des activités importantes. Elles méritent un peu de considération pour leur longévité, même si une modernisation s’impose.

Et vous, quelles sont vos expériences avec les projets de legacy PHP ? Avez-vous obtenu de meilleurs résultats avec une réécriture ou un refactoring ?

Cet article s'inspire d'une discussion sur les défis et les réalités du développement d'applications avec un legacy PHP dans un contexte professionnel actuel.