La deuxième loi de la thermodynamique, dans ses principes, énonce que la désorganisation d’un système fermé ne peut pas être diminuée, mais seulement rester inchangée ou augmenter. Une mesure de cette désorganisation est l’entropie. Cette loi semble aussi s’appliquer aux systèmes logiciels; quand un système est modifié, sa désorganisation, ou entropie, augmente systématiquement. Cela est connu sous le terme d’entropie logicielle.
Ivar Jacobson (traduit depuis l’anglais)
Entropie logicielle et dette technique
L’entropie logicielle est un principe intimement lié à la notion de dette technique. Commençons par définir celle-ci, il s’agit de l’ensemble des coûts cachés qui grèvent la rentabilité d’un logiciel :
- Le coût lié à la perte de productivité des développeurs face à un code source incohérent, inutilement complexe ou de mauvaise qualité : perte de temps pour comprendre le fonctionnement du programme et rechercher de l’information.
- Le coût lié à la correction de bugs : perte de temps pour corriger des dysfonctionnements (si cela touche un utilisateur final, il y a en plus une perte d’image pour le logiciel).
- Le coût de modification du code source : le logicielle devient de plus en plus difficile à modifier sans effet de bord (défaillances en cascades sur d’autre partie du logiciel).
Ces effets sont cumulatifs : l’ajout d’une fonctionnalité provoque un effet de bord, menant à une défaillance difficile à retrouver à cause de l’incohérence du programme…
Par ignorance, la dette technique est malheureusement rarement prise en compte.Mais aussi par le fait qu’évaluer la perte liée à la dette technique est un exercice complexe : les coûts sont liés à une perte de productivité et donc très difficiles à évaluer. Enfin corriger et prévenir la dette technique (améliorer le code source) est souvent considéré comme un investissement inutile car n’apportant aucune fonctionnalité supplémentaire, tout en pouvant ralentir le projet en consommant du temps de développement.
Pourtant, imaginons que vos développeurs passent 2 heures par semaine à chercher “comment faire” et à corriger des défaillances sur des logiciels existants. Multiplions ces heures par le nombre de semaines travaillées dans l’année (~44) nous obtenons 88 heures, soit 2,5 semaines de développements (journée de 7 heures). Pour une petite équipe de cinq personnes, la perte est de 3 mois hommes ! Avec l’hypothèse d’un coûts salarial de 4000€ mensuel, la perte se chiffre à 12 000€ par an ! Alors que nous avons une toute petite équipe et en sachant que le chiffre de deux heures par semaine est déjà très optimiste. Dans la majorité des cas vous pouvez le multiplier par 3 ou 4 (et appliquer le même multiplicateur sur vos pertes).
De l’autre coté le principe de l’entropie logicielle énonce que naturellement votre dette technique ne fait qu’augmenter avec la durée de vie de votre produit : l’ajout de fonctionnalités augmente la taille du code source et donc sa complexité. C’est pourquoi, sans contre-mesure concernant l’entropie logicielle, votre produit verra ses coûts de production et de maintenance augmenter mécaniquement jusqu’à atteindre un seuil où la rentabilité du logiciel sera remise en cause.
Si en France la terminologie consacrée parle “d’érosion de l’architecture logicielle”, la terminologie anglaise est plus parlante en utilisant le terme de “software rot” soit “niveau de pourriture” du logiciel.
L’entropie n’est cependant pas une fatalité grâce à un ensemble de bonnes pratiques d’ingénierie logicielle. Dans la suite de cette article nous allons nous intéresser à ces facteurs qui accélèrent ou au contraire ralentissent l’entropie d’un logiciel et donc sa tendance à générer de la dette technique. Enfin Les architectes, en tant que garant de la maintenabilité du logiciel sont très sensibles à cette notion (si ce n’est pas le cas, changez d’architecte), malheureusement trop souvent laissée de côté par les instances managériales.
Lutter contre l’entropie
Lutter contre l’entropie revient à lutter contre la nature même de l’évolution d’un projet logiciel, c’est pourquoi vous devez mobiliser vos développeurs pour les aider à combattre cette évolution.
La première mesure est psychologique, tout le monde a pû remarquer que si certaines habitations sont bien tenues, propres et rangées d’autres sont au contraire en désordre sale et où l’on n’y retrouve rien. Dans le logiciel c’est la même chose, vous pouvez avoir des développements propres et bien entretenus et à l’inverse des code sources complètement dégradés. Ainsi votre première ligne de défense contre l’entropie est vos développeurs : ils doivent y êtres sensibilisés et prendre soin de leurs développements.
Dans ce cadre, intéressant de parler de la théorie criminalistique de la vitre cassée (notamment mise en oeuvre à New York avec de très bon résultats), l’exemple donné est le suivant :
Imaginez un immeuble avec quelques fenêtres brisées. Si les fenêtres ne sont pas réparées, des vandales vont avoir tendance à briser les autres vitres. Et même pénétrer dans l’immeuble pour en faire un squat.
En effet, pensant que le bâtiment n’est plus occupé ni entretenu des vandales vont se sentir le droit d’en augmenter la dégradation. C’est un principe universel et je pense que toute personne a déjà fait l’expérience que le désordre amène toujours plus de désordre.
Le parallèle avec le milieu du développement n’est pas anodin. Un développeur travaillant sur un code source de mauvaise qualité se laissera aller sans faire d’effort pour améliorer la situation. Au contraire d’un développeur travaillant sur un code source d’excellente qualité : plus précautionneux, augmentera de lui même le niveau de son développement. Vous devez donc surveiller l’apparition de code de mauvaise qualité (vos “vitres cassées”) et le réparer au plus vite avant que la situation ne se dégrade. Il est à noter que travailler perpétuellement sur des codes de mauvaises qualités va gréver la motivation de vos développeurs diminuant d’autant leur productivité.
Pour aider à la détection de ces “vitres cassées” et transmettre cet état d’esprit au sein d’une équipe, les revues de code en groupe se placent comme des outils de choix. Il suffit d’être plus de deux personnes, de prendre un morceau de code source (si possible de l’un des participants) et le commenter collectivement pour proposer des améliorations (une revue de code doit aussi montrer des exemples d’implémentations de bonnes pratiques dans le code source). Attention, ces séance ne doivent pas être à charge pour le développeur dont le code est audité, les critiques doivent être constructives. La préparation de ces événements peut être réalisée par un architecte logiciel dans un but pédagogique, ou auto-organisées entre développeurs. Bénéficier du regard d’autrui sur un code source est l’une des meilleure façon de progresser.
De façon plus opérationnelle, la méthode de lutte contre l’entropie logicielle passe par du “refactoring”. C’est à dire améliorer constamment le code source en factorisant les processus similaires : la duplication de code étant l’un des facteurs accélérant le plus l’entropie logicielle. Afin de ne pas introduire de régressions fonctionnelles pendant cette étape, les tests unitaires sont indispensables. Si votre logiciel n’est pas testé, vous pouvez démarrer au fur et à mesure des travaux de refactoring en testant progressivement le code source. L’absence de test ne devant pas être une excuse pour ne pas exécuter ce type de travaux.
Supprimez aussi tout code inutile, un morceau de code source ne servant plus à rien doit être supprimé, le logiciel de gestion de version des sources gardant l’historique du code vous pourrez le récupérer à posteriori si nécessaire.
Enfin un dernier conseil pratique : dès qu’un bug est identifié, écrivez d’abord le test unitaire le provoquant puis corrigez le bug. De cette façon vous êtes certain qu’il ne se reproduira plus. C’est un bon moyen de démarrer une campagne de tests pour une application existante. Dîtes vous que non seulement vous remplacez la vitre, mais en plus vous installez un détecteur de bris de glace.
En terme d’architecture logicielle, la simplicité est votre meilleure alliée, un système simple est moins sujet à l’entropie et donc plus facilement maintenable. En découpant un logiciel en une série de composants indépendant vous transformez une application monolithique en un agrégat de modules simples travaillant de concert. Ces approches sont connues sous le terme d’Architecture Orientée Service.
Conclusion
L’entropie logicielle et la dette technique sont des sujets trop souvent ignorés et souvent mal acceptés : leurs réductions nécessitent une réflexion sur le long terme, qui n’est pas toujours en adéquation avec les besoins de mise sur le marché. Cette vision au long terme est cependant indispensable si votre business modèle repose sur le bon fonctionnement et la capacité d’évolution de systèmes logiciels.
Au niveau des outils, les serveurs d’intégrations continus pourront vous apporter une aide précieuse : en exécutant des tests par une analyse du code source, ces serveurs analysent la qualité du développement en temps réel, fournissant des retours de grande valeur aux développeurs pour savoir s’ils vont dans la bonne direction.
Enfin la mise en place d’une pratique rigoureuse de méthodes agiles d’architecture logicielle comme l’ “Emergent Design”, permet de construire des applications plus résistantes à l’entropie logicielle. Pour plus d’informations sur ce sujet, vous pouvez lire la série d’articles sur les architectures agiles.
Illustration issue de wikipedia
Si vous avez ce type de problématique, ma société : Ibsciss vous apporte un large panel de prestations sur ces sujets.
Arnaud LEMAIRE 
Excellent article, le contenu est riche, claire et précis ! Merci beaucoup pour la qualité du travail que vous fournissez.
Ca me permet de compléter ce que j’apprends en cours notamment en gestion de projet informatique et d’avoir une autre approche du métier de développeur.