Une application qui contribue pleinement à la création de valeur dans l’entreprise mais dont la conception n’est plus vivante, est ce qu’on appelle dans notre jargon technique une application “legacy”.

La définition élégante proposée par Nicolas Carlo va dans ce sens :

Legacy Code is valuable code you’re afraid to change.

Cette situation n’est pas nécessairement un problème. Certaines solutions peuvent durer longtemps sans qu’il soit nécessaire pour l’entreprise d’y apporter des changements. Elles peuvent même finir par “migrer” vers la droite dans une carte de Wardley c’est à dire devenir des commodités. Lorsque la complexité essentielle d’une application peut être absorbée par un acteur extérieur et faire l’objet d’une fourniture industrielle, cela indique que la solution a été “rationalisée” et que l’évolution de sa conception ne constitue plus un enjeu stratégique.

En revanche, lorsqu’une solution apporte une valeur stratégique à l’entreprise, alors selon toute probabilité, des changements importants touchant sa conception vont être projetés, négociés, parfois plus ou moins imposés. Sa conception a besoin de vivre. 🩺

C’est la raison pour laquelle une équipe de développement écrit des tests, des commentaires et de la documentation. 📐📝ℹ️

C’est aussi la raison pour laquelle elle remanie le code : si elle peut donner à son code une expressivité suffisante, alors le code sera plus facile à changer, même si on n’écrit pas de commentaire ni de documentation ! 😎

Voici un exemple trivial :

Supposons que dans la conception d’une application, partout où la TVA doit être calculée, des programmeurs (inconscients) ont écrit :

  prixTTC = prixHT * 1.20

Pour que ce code soit facile à changer, deux tactiques possibles.

Tactique A :

✅ chaque chemin d’exécution du code où une TVA est calculée fait l’objet d’un test auto-vérifiant

🔬 l’emplacement du code où se situent ces calculs peut être retrouvé dans une liste ou par extraction

🤓 note explicative sur ce qui peut arriver lorsqu’on fouille du code à l’aide de l’expression régulière * 1.20

Tactique B :

📦 le calcul de la TVA fait l’objet d’un module TauxTva

✅ ce module est équipé de ses propres tests auto-vérifiants

🧐 les contraventions à son usage sont détectées et discutées lors de la relecture du code

Supposons que ces programmeurs, extraits de leur léthargie au beau milieu du sprint par la remarque d’un stagiaire, réalisent qu’ils ont besoin d’appliquer la tactique A ou B. Ils en touchent un mot au PO qui leur tient à peu près ce langage :

_ Foin des refactorings ! Vous vous ferez plaisir après la mise en prod.

L’équipe referme ce dossier. Le logiciel est livré en prod. Après la mise en prod, il y a tellement de choses nouvelles à faire…

Dans 5 ans une équipe va ouvrir le capot : whaaaat ?

🕸🧟‍♀️🧟🧟‍🕸

En fait, c’était le refacto de la dernière chance. 🪦

publié sur LinkedIn le 09/03/2023