Le code legacy se dégrade avec le temps

Le code legacy ne vieillit pas comme le vin. Il se dégrade chaque jour où vous l'ignorez.

La semaine dernière, j'ai passé trois heures à déboguer un problème qui aurait dû prendre 20 minutes. Le coupable était un module de validation de 2019. On l'avait laissé tranquille parce qu'il fonctionnait. En réalité, il ne fonctionnait pas. J'ai trouvé un commentaire « TODO: refactor this » datant de 2020.

Beaucoup considèrent le code legacy comme une dette optionnelle. Ils pensent qu'ils la rembourseront quand ils auront le temps. Le code legacy agit comme de la moisissure. Il se propage. Il infecte tout ce qui l'entoure. Plus vous attendez, plus le nettoyage devient coûteux.

Le cycle est prévisible :

  • Vous héritez d'une fonctionnalité désordonnée mais fonctionnelle.
  • Vous ajoutez une instruction « if » supplémentaire pour la faire fonctionner.
  • Six mois plus tard, quelqu'un d'autre fait la même chose.
  • Un an plus tard, le fichier fait 800 lignes et ne possède aucun test.

Ce coût caché vous frappe de trois manières :

  • La vitesse chute. Vous passez plus de temps à comprendre le contexte qu'à écrire du code.
  • Les bugs prolifèrent. Un correctif casse autre chose parce que la logique est emmêlée.
  • L'onboarding échoue. Les nouveaux développeurs peinent à comprendre pourquoi la même logique existe à sept endroits différents.

Surveillez ces signaux d'alerte :

  • Des commentaires inutiles comme « HACK: do not touch this. ».
  • De la logique métier dupliquée dans différents fichiers.
  • Des dépendances circulaires où les services dépendent les uns des autres.

Ne réécrivez pas tout. Les réécritures complètes échouent dans 80 % des cas. Utilisez plutôt un refactoring incrémental avec des tests de caractérisation.

Suivez ce processus :

  • Capturez le comportement actuel avec des tests, même les parties étranges.
  • Refactorez le code sans changer ce comportement.
  • Répétez l'opération jusqu'à ce que le code soit lisible.
  • Ne changez le comportement qu'une fois que vous avez de vrais tests.

Règles à suivre :

  • Ne refactorez jamais sans tests.
  • Évitez les améliorations qui modifient le comportement du code. Un bug peut être une fonctionnalité sur laquelle un client s'appuie.
  • Laissez le code calme tranquille. Si un module n'a pas changé depuis trois ans et ne pose aucun problème, n'y touchez pas.

Concentrez votre énergie sur le code que vous modifiez souvent.

Source : https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h