Le concept de dette technique apparaît dans les années 90 par Ward Cunningham, inventeur du concept du Wiki, pour évoquer la pérennité et l'évolution des développements informatiques dans le temps.
Le principe :
Le code source d'un programme doit être conçu de manière à être le plus cohérent possible et respectant les normes en vigueur afin de faciliter les maintenances correctives et évolutives du programme. Tous les projets de développement informatique ne se terminent pas à leur mise en service. Des correctifs, des adaptations et des mises à jour de sécurité se manifesteront par la suite à plus ou moins long terme. On parle alors de dette technique lorsque les maintenances qui seront à réaliser dans le futur auront un coût supplémentaire sur l'ensemble du projet. Ce sont les "intérêts ".
Les non-respects de la conception, intentionnels ou non, introduisent des difficultés pour les développements à venir.
Les origines d'une dette technique
Une dette technique non intentionnelle
Une dette technique non intentionnelle est liée à des malfaçons souvent dues au non-respect de la conception et des règles de codage. Elle apporte aucun bénéfice au projet.
Une dette technique intentionnelle
Une dette technique peut être intentionnelle dans le sens où la qualité du code source augmente la charge de travail. Afin de respecter des délais de livraison, pour la sortie d'une nouvelle version d'un logiciel par exemple, le choix de ne pas respecter des règles de conception pour éviter des retards peut être fait. Ce choix permet avant tout d'atteindre l'objectif prioritaire à court terme : livrer le code source pour la sortie d'un nouveau produit. Ce choix sacrifie la qualité du produit sur le long terme. Il est tout de même conseillé de reprendre le code source après avoir répondu aux objectifs prioritaires (livraison) pour éviter que la dette technique soit trop importante par la suite.
Minimiser la dette technique
Pour éviter d'avoir une dette technique trop importante, il est conseillé de suivre les règles suivantes :
- Respect de la conception et des règles de codage : cela correspond à l'organisation des fichiers du code source, au style d'indentation, au respect des règles de nommage, à l'ajout de commentaire dans le code source.
- La mise en place d'une documentation, et des spécifications.
Le respect de ces règles apporte de la lisibilité au code source et facilite la reprise du développement par d'autres experts (dans le cas, où la personne qui gère votre projet part à la retraite, ou l'entreprise à qui vous avez fait appel ferme boutique, etc.)
Par ailleurs, un cahier des charges précis et clair permet d'éviter certains problèmes lors d'un projet de développement.
