Ce code a 10 ans. Personne n'ose y toucher.
Le syndrome du code radioactif. On tourne autour, mais on n'entre pas.
"Ce module-là, on n'y touche pas. La dernière fois qu'on a essayé, on a cassé la prod pendant 2 jours."
J'entends ça sur 80% des projets legacy que je reprends.
Les symptômes du code legacy toxique :
- 😰 Peur de modifier quoi que ce soit
- 🤷 Personne ne comprend vraiment comment ça marche
- 🐛 Bugs récurrents impossibles à tracer
- ⏱️ Temps de développement x3 sur les nouvelles features
- 😤 Développeurs frustrés qui partent
Pourquoi c'est arrivé ?
- Pas de tests → impossible de refactorer sereinement
- Turnover → connaissances perdues
- Pression business → "on fera propre plus tard"
- Dette technique accumulée → intérêts exponentiels
Comment reprendre un projet legacy (sans tout casser) :
1. Cartographier avant d'agir
Comprendre ce qui existe. Schémas, flux, dépendances. On ne répare pas ce qu'on ne comprend pas.
2. Ajouter des tests sur les chemins critiques
Pas tout tester. Juste le cœur métier. Pour pouvoir modifier en confiance.
3. Strangler Pattern
Remplacer progressivement les modules legacy par du code neuf. Sans big bang.
4. Refactoring par petites touches
Boy Scout Rule : laisser le code plus propre qu'on ne l'a trouvé. À chaque passage.
5. Documenter au fur et à mesure
Chaque découverte = une note. Pour les suivants.
Résultats sur un projet récent :
- Application Symfony 2.8 → Symfony 7.4
- Durée : 4 mois (progressif, pas de big bang)
- 0 interruption de service
- Vélocité équipe x2 après migration
La leçon ?
Le code legacy n'est pas une malédiction. C'est un patient à soigner. Avec méthode et patience. 🎯
Vous avez une application PHP legacy qui vous bloque ?
👉 Contactez-moi. Audit, stratégie de modernisation et accompagnement.