[Agile 2015]
Old Code, New Tricks (pas technique)

Félix-Antoine Bourbonnais
3 min readAug 3, 2015

--

Conférence de Scott Fort, Corgibytes
Agile2015, lundi AM, http://sched.co/36Nx
Diapositives: http://fr.slideshare.net/mscottford/old-code-new-tricks-75-minutes

Ceci est un résumé écrit rapidement en direct de la conférence. Soyez indulgent.

À retenir

  • Le mot clé n’est pas de livrer, mais garder stable (ce qui ne rend pas l’autre moins important)
  • Des gens très professionnels peuvent adorer travailler dans le code « Legacy » pour l’améliorer
  • Le langage utilisé dans le « Legacy » nous force à refaire… Changeons notre vocabulaire!
  • Utilisons les outils et pratiques modernes, même si le code est vieux
  • Le mot « estimation » pose problème. Voyons cela comme des
    « prévisions »

Résumé

Le métier de rénovateur de code

On dévalorise souvent ceux qui aiment travailler dans le code patrimonial (Legacy). Dans la réalité, plusieurs « Craftsman » voulant faire de la qualité aiment travailler dans du « vieux » code. Ce sont les rénovateurs* de logiciel.

Dans la phase « d’évolution » l’important n’est pas tellement de livrer vite, mais de le garder stable. C’est un travail d’endurance.

Ces rénovateurs aiment réduire la complexité en utilisant des outils et approches modernes.

Tournez votre langue 7 fois

Un des problèmes provient du langage que l’on utilise pour le « Legacy Code »: toujours négatif! Exemple: Legacy, Big Ball of Mud, Brown Field (versus Green Field) …

Le présentateur suggère alors d’utiliser plutôt des termes comme : Vintage, Remodeling, Révitalize

On attirerait ainsi, peut-être, plus de bons professionnels qui veulent faire de la qualité, mais dont la passion est de « revitaliser » le code écrit à une autre époque. Un peu comme pour la revitalisation d’un quartier ou d’une maison.

Dans le même ordre d’idée, ce n’est pas un Sprint Scrum, mais une Itération… On ne sprinte pas pour livrer, on itère pour rester stable et améliorer les choses.

J’ai une maison des années 40 alors il est interdit d’utiliser une perceuse!

On devrait toujours essayer d’utiliser les outils les plus récents même si le code est vieux.

Si vous avez 40 ans, est-ce vous voulez que votre médecin vous soigne avec les connaissances d’il y a 40 ans?

Si votre maison date des années 30… pourquoi on ne pourrait pas utiliser les techniques ou outils modernes? Et on va la mettre aux normes non?

C’est ça le « remodelage » (réusinage) de code…

L’effet du temps

Pour dans le logiciel est-ce forcément mauvais du « vieux code ». Vous pouvez acheter une maison des années 60… vous savez qu’elle a besoin de rénovation pour la mettre à votre goût, peut-être que la toiture est à refaire… ***

Logiciel utile → Modifications constantes dans le temps → Augmentation de la complexité
Sauf si on s’y attaque continuellement.

Plus ça fait longtemps que l’on a pas touché à un bout de code → plus il sera difficile de le changer

Estimations?

Au passage, le présentateur mentionne qu’en Agilité on devait peut-être éviter le terme « estimation » car il fait référence à l’estimation reçue pour un travail ponctuel (ex.: estimation pour réparer ma voiture). Dans notre domaine nous donnons des prévisions (forcast) comme pour la météo. Qui se trouve assez brillant pour donner une prévision météo pour dans 1 an incluant la température à 2 dégrés près?

*Le conférencier utilisait le terme « mender » (réparateur), mais je pense qu’en français, rénovateur colle plus à sa présentation.

*** Ceci est une extrapolation du contenu de la conférence.

PS. Ceci est un résumé et ne reflète pas forcément mon opinion ou celle de mon employeur.

--

--

Félix-Antoine Bourbonnais

Software engineering trainer + coach. Automated tests (TDD ATDD …), Emergent Design Architecture & DDD, BDD, DevOps & Agile | http://conference.elapsetech.com