1. L’explication :
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.
2. La provenance 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 n’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 à 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.
3. D’où arrive la dette technique ?
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é.
4. Pourquoi il est important de s’en préoccuper ?
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 :
- il devient impossible de faire évoluer rapidement les plugins
- chaque mise à jour nécessite des études d’impact fort
- on ne peut plus faire évoluer un site car le plugins est obsolète
- une nouvelle mise à jour sort et on ne peut pas du tout s’y adapter car elle n’est pas compatible avec le thème ou les fonctionnalités choisies en premier lieu.
En effet, si vous vous retrouvez dans un des cas ci dessus, alors il est temps de se préoccuper de la dette technique.
5. Minimiser la dette technique
Pour éviter d’avoir une dette technique trop coûteuse, il est conseillé de suivre les règles suivantes :
- Respecter 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.
- Mettre en place 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. 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.