Il y a cette manie qui traîne, cette idée que si quelque chose n’est pas dans un fichier de configuration, un outil manque de souplesse. Que si il n’y a pas un settings['truc'], ça va être compliqué si on veut le changer plus tard.

Et dans de nombreux langages bas niveaux, ça se vérifie.

Mais quand on code en Python, Ruby, PHP ou Javascript, et d’autant plus avec des gros frameworks d’abstraction, le code est déjà une forme de configuration.

Souvent les clients me demandent de découpler mon code pour le rendre plus souple, plus flexible. Avec des options pour le rendre configurable. Et c’est une bonne chose.

Cependant il faut comprendre qu’il y a déjà tellement de design patterns embarqués dans nos outils modernes (iterator, generator, indexable, sliceable…), tellement de facilités offertes par les paradigmes actuels (typage dynamique, late binding, duck typing, bytecode, etc.) qu’un programme qui n’a pas été écrit comme un porc propose déjà une large marge de manœuvre.

Il est vrai qu’avec l’expérience, on écrit plus vite un code de meilleur qualité, et que, naturellement, on a tendance à laisser des hooks par ci, des opportunités d’injecter des dépendances par là. Surtout si on fait des tests unitaires.

Néanmoins, trop souvent, il sera demandé de pouvoir “rendre cette partie adaptable”, “faire en sorte qu’ici on puisse switcher d’implémentation” ou “je veux pouvoir changer d’avis plus tard”.

On peut déjà le faire.

Je suis programmeur, Python me parle. Un bon dev de la même techno trouvant mon code pourra modifier une bonne partie de mon travail pour obtenir un résultat différent.

Il n’y a pas forcément besoin d’une entrée en plus dans le .ini|json|conf|bak|old|~|/dev/null, d’un paramètre backend, de 2 jours de taf de plus pour rendre adaptable quelque chose qui peut être édité facilement.

De nombreuse fois, il est plus aisé de modifier, casser, remplacer, et même copier / coller.

Ce n’est pas écrit dans les bouquins sur les bonnes pratiques, mais c’est notre métier de coder. On est bons pour ça. On est rapides. Efficaces.

Si la fonctionnalité est un besoin avéré qu’il faudra pouvoir activer et désactiver en prod, bien entendu, il faut une option.

Mais si il faut couvrir un besoin futur hypothétiquement potentiel, laissez le dev décider si c’est YAGNI, on peut gagner beaucoup en productivité en pariant que modifier le code quand le besoin se présentera est la démarche la plus simple.

L’équilibre entre la dette technique et la sur-ingénierie permet de garder un projet sur les rails.