Le système de valeurs

Nous souhaitons commencer cette section par une thèse qui peut sembler provocante :

Il n'y a pas de maintenance logicielle !

La maintenance est un processus proactif. Dans les installations de production, les pièces sont régulièrement remplacées avant qu'elles ne soient cassées. Elles sont remplacées parce que l'expérience montre que la fiabilité tomberait en dessous d'une valeur critique si elles continuaient à fonctionner. Avant que toute l'installation ne s'arrête, les pièces critiques sont donc remplacées à temps. Chaque propriétaire de voiture sait qu'il doit faire régulièrement une vidange d'huile. Non pas parce que l'huile est épuisée à ce moment-là, ni même parce que l'huile est déjà totalement inefficace à ce moment-là. Non, elle est remplacée parce que les valeurs empiriques du fabricant montrent que le moteur est ménagé par une vidange effectuée à temps et qu'il dure donc plus longtemps.

Tout cela n'existe pas avec les logiciels. Le logiciel est tel qu'il est. La plupart du temps, il contient des erreurs. Mais ces erreurs sont aussi ce qu'elles sont. On ne peut rien faire de manière proactive pour améliorer l'état du logiciel.

Il y a bien sûr des actions pro-actives dans le fonctionnement du logiciel. Il faut peut-être vérifier régulièrement si les fichiers journaux laissent encore suffisamment d'espace libre sur le disque dur, si une base de données déborde ou si la mémoire se remplit de plus en plus. Mais le logiciel en lui-même ne peut pas être entretenu de manière proactive. Toute modification ou extension a lieu pour éliminer une erreur ou pour mettre en œuvre des exigences nouvelles ou modifiées.

Pour que des changements soient possibles, le logiciel doit avoir une structure interne qui favorise de tels changements. C'est ce que nous appelons la mutabilité. En règle générale, les logiciels sont exploités sur de longues périodes. Pendant cette période, les conditions générales changent et des fonctionnalités doivent être ajoutées. Dans l'idéal, l'implémentation d'une fonctionnalité coûte un montant fixe, indépendamment du moment où la fonctionnalité est réalisée.

Dans la pratique, le prix d'une fonctionnalité augmente au fur et à mesure qu'elle est mise en œuvre. Au début, les fonctionnalités sont bon marché, mais à la fin, il n'est même plus possible d'ajouter des fonctionnalités, car personne n'y voit plus clair. Le logiciel est jeté et redéveloppé. Jusqu'à ce que l'on arrive à ce point, les coûts augmentent de manière exponentielle. La croissance exponentielle a deux inconvénients : 1) au début, on ne se rend pas compte que les coûts augmentent. Les augmentations sont modérées. 2) Lorsque l'on se rend compte que les coûts augmentent, il est trop tard. L'augmentation est alors si rapide qu'il n'est plus possible de la contrecarrer.

Plus le logiciel peut être adapté facilement à des conditions générales modifiées, plus sa mutabilité est élevée. Mais la mutabilité ne s'obtient pas après coup. Elle doit être prise en compte dès le départ. Le logiciel doit être conçu en conséquence.

Un exemple : les classes devraient avoir une seule responsabilité. Si une classe est responsable de plus d'une chose, il est plus difficile d'en avoir une vue d'ensemble. Cela entrave les modifications, car celles-ci nécessitent de comprendre le code source qui doit être modifié. De plus, le couplage entre les classes augmente. Soudain, tout est lié à tout. Pour éviter cela, il faut que les unités fonctionnelles aient une responsabilité clairement définie et que l'on garde un œil sur le couplage. Si l'on a accumulé dans un système logiciel une série de classes qui sont chacune responsables de plusieurs choses, il est difficile de remédier à cette situation après coup. Le couplage est si important qu'il est difficile de séparer les différentes unités fonctionnelles. Si l'on veut réaliser de nouvelles fonctionnalités dans ce maquis, cela demande beaucoup de travail. Si l'on ne commence pas à temps à éclaircir le maquis, la situation s'aggrave à chaque fois. À partir d'un certain point, il n'est plus guère possible d'ajouter de nouvelles fonctionnalités. C'est le super GAU du développement logiciel.

Nous pensons qu'il n'est pas nécessaire d'en arriver là. Si l'on tient compte de la mutabilité dès le départ, les logiciels peuvent être développés sur une longue période. Les coûts par fonctionnalité peuvent augmenter légèrement au fil du temps. Mais en aucun cas de manière exponentielle !