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 pour faciliter les maintenances correctives et évolutives du programme. Tous les projets de développement informatique ne se terminent pas à leur mise en service. Des maintenances, des adaptations et des mises à jour de sécurité se manifestent par la suite, ce qui peut être plus ou moins long. 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 ».
Donc, les non-respects de la conception, intentionnels ou non, introduisent des difficultés pour les développements futurs.
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 n’apporte aucun bénéfice au projet.
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 à temps 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.
Elle s’accumule un peu chaque jour sur la base de différents points, avant même d’écrire la première ligne de code. Les technologies évoluent, les recherches se multiplient et les savoir-faire s’améliorent très rapidement. La dette technique est liée à la taille d’un projet et à son niveau de qualité global. Plus un projet contient de code et de fonctionnalités et plus sa maintenance devient minutieuse. Il y a plus de productivité inévitable qui s’applique pour les projets plus qualitatifs.
Au-delà, de cette complexité importante il existe d’autres facteurs qui ont un impact bien plus significatif. Tous ces facteurs sont en liens étroit avec la capacité à faire évoluer rapidement une base de code, notre agilité.
Ou à l’inverse, que se passe t-il si l’on ne s’en occupe pas ? Inévitablement, la dette technique se forme et augmente, de manière non visible mais absolument réelle. Premièrement elle aura peu d’impacts, puis avec le temps, elle va augmenter de façon croissante.
Au quotidien, voici les manifestations de la dette technique :
En effet, si vous vous retrouvez dans un des cas ci dessus, alors il est temps de se préoccuper de la dette technique.
Pour éviter d’avoir une dette technique trop coûteuse, il est conseillé de suivre les règles suivantes :
Le respect de ces règles apporte de la lisibilité au code source et facilite la reprise du développement par d’autres experts. Par ailleurs, un cahier des charges précis et clair permet d’éviter certains problèmes lors d’un projet de développement.
Avant l’écriture d’une première ligne de code il convient de savoir dès le départ s’il est plus important d’y mettre certaines fonctionnalités pour éviter des frais trop coûteux par la suite dues aux mise à jour etc..(par exemple pour un projet à long terme); ou au contraire, si vous préférez ne pas le faire car votre projet est mis en place pour une durée à court terme et vous pensez que cela n’engendra pas de grosses conséquences pour le travail à fournir dans le futur.