Une erreur de débutant
En 1996, tout frais sorti d’école d’ingénieur, je débutais plein d’enthousiasme par un joli défi technique.
Mon premier job concernait l'industrie.
Ma mission était de réduire le nombre d’équipements numériques nécessaires à faire fonctionner une usine.
Parce que les serveurs ou les armoires de contrôle-commande, ça coutait un bras.
En travaillant mon sujet, je me suis aperçu que les serveurs étaient généralement sous-utilisés. En répartissant le code autrement, on pouvait augmenter le taux d’utilisation de chaque serveur, sans impact sur les performances globales.
Toute la difficulté consistait à optimiser la répartition du code, tout en respectant la capacité max du réseau interconnectant les serveurs.
Après s’être un peu creusé le cerveau, je parvenais à économiser 20% du matériel initialement prévu.
Bingo !
(NB pour les jeunes ingénieurs : vous allez passer l’essentiel de votre temps à résoudre des problèmes d’optimisation).
Ce n’est que 10 ans plus tard que j’ai compris mon erreur...
Lorsqu’il m’a fallu éteindre l’un des serveurs pour remplacer une carte électronique.
Une grosse boule de gadoue
Parce qu’en ré-organisant le code, j’avais involontairement créé une grosse boule de gadoue (adaptation personnelle de la "big ball of mud" que tous les devs redoutent).
Et oui.
Le code nécessaire à une fonction était tartiné à plusieurs endroits, sur plusieurs serveurs.
En ne regardant QUE la réduction du matériel, j’étais passé complètement à côté de la maintenabilité.
Il n’était plus possible d’éteindre un seul serveur. Il fallait TOUT arrêter !
Avec à la clé, un manque à gagner financièrement plus lourd que les 20% de serveurs en moins (dont le prix unitaire avait été divisé par 10 entre temps, s’il fallait le préciser).
En raisonnant à court-terme, j’avais malgré moi créé un bazar couteux à maintenir sur le long terme.
OK. Je noircis un peu le tableau, parce que le code n’était pas si bien organisé au départ.
Mais mon optimisation n’avait pas arrangé les choses, au contraire.
Sens unique
Mais qu’est-ce qui fait que le schéma "arborescent" (à gauche) nous semble beaucoup mieux conçu qu’un plat de spaghetti (à droite) ?
Regardez bien.
La réponse est toute simple.
Les flèches ne vont que dans un seul sens.
Un. Seul. Sens.
C'est l'un principe de conception d’un code durable.
Avec le recul, je trouve que c’est le plus important.
Les cascades d’appels entre les modules (= les dépendances) doivent toujours aller dans le même sens.
Mais pour respecter ce principe, il faudra probablement davantage de lignes de code.
Et il y aura toujours quelqu’un qui voudra faire des économies. Sous prétexte que "la ligne de code la plus fiable est celle qu’on n’écrit pas".
Si ça vous arrive, racontez-leur mon histoire !