Est-ce que tu peux rendre ça configurable ? 6


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.

6 thoughts on “Est-ce que tu peux rendre ça configurable ?

  • toub

    d’autant plus que le sur-ajout de configurabilité tend à rendre le code rapidement imbittable!
    Après la difficulté reste de pondre une bonne architecture dans laquelle on pourra facilement compléter et/ou remplacer les éléments pour modifier le comportement. Et ça selon mon expérience c’est pas toujours le cas malheureusement …

  • roro

    Loin de moi l’idée de te réprimander pour faire sur ton blog de la propagande pour les codeurs/développeurs;
    Mais quand tu parle de: “design patterns embarqués”; tu parle bien de tripatouiller le code.
    Le client, il ne tripatouille pas.
    Alors tous tes tripatouillages, tu leur affecte un bouton chacun, tu en fais un bouquet, que tu rends accessible par un bouton que tu peint en vert et que tu colle dans un coin. On appelle ça: Une interface.
    Deux jours de boulot ? Putan…! ça fait cher le bouton.
    Ceci dit, je suis d’accord que pour des modifs, ben faut tripatouiller.

  • Sam Post author

    Je ne parle pas ici de fonctionnalités pour client final mais pour les fonctionnalités métiers. Bien entendu, pour l’utilisateur du produit, et non du code, la démarche est tout autre.

  • Sylvain

    Ahhhh c’est bon de lire ça ! Je me sens moins seul !
    Combien de fois je me suis frité avec des collègues sur ce sujet ? Rajouter du gras dans le code pour des modifs hypothétiques qu’on ne fera jamais j’ai toujours trouvé ça débile. Sans compter les formats de conf impossible à commenter comme le JSON… Mais pourquoi se compliquer la vie quand le client n’a rien demandé ? D’autant qu’avec des conf dans tous les sens c’est souvent plus pénible à debugger. C’est comme les devs bilingues comme ma grand mère qui te collent des modules de traduction partout alors que l’appli sera toujours en français…

Leave a comment

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.