En tant qu’expert, j’ai peur de modifier le code. En modifiant module
A
cela peut casser le moduleB
.
Mon manager me met la pression pour livrer, donc je livre. À la fin de la journée de travail, j’ai du mal à me regarder dans le miroir.
Un peu plus tard, plusieurs utilisateurs remontent une série de régressions.
Je connais bien ce contexte de code legacy, adjoint à une pression continue de livrer.
Il y a une seule manière de répondre à cette problématique.
Faire face au problème et corriger petit à petit la structure du code.
Faire face au problème veut dire que le nombre d’évolutions va diminuer considérablement.
En passant de la course à la marche lente.
Et donc avancer à la vraie « vitesse ».
Je plonge dans mes archives de veille
Je trouve un épisode de ScrumLife
Toutes les réalisations d’aujourd’hui seront le legacy de demain.
Elles se transforment en pourriture, lorsque tu as peur d’y toucher.
Nettoyer cette pourriture, c’est plus compliqué que d’enlever de la poussière sur un meuble.
As-tu déjà travaillé sur une application dite « legacy » ?
En quelques mots : c’est une véritable galère.
— Jean-Pierre et Constantin