Julien Carnelos Blog – Archives

Le principe de la dette technique est fondamental en ingénierie logicielle.

Lorsque vous ajoutez une fonctionnalité, vous avez toujours un choix :

• Faire le plus rapide, crade mais qui marche
• Prendre le temps de réaliser proprement avec une architecture et un design stable

La métaphore de la dette technique nous explique qu’une solution à court terme crée une dette technique dans notre programme. Et comme pour une dette monétaire, plus la dette grandit et plus les intérêts deviennent important.

Vous avez sûrement déjà connu des programmes ayant subi évolutions après évolutions et se retrouvant dans un état où la moindre modification risque de tout saboter. A ce niveau, la dette technique est trop grande et le logiciel est dans une « banqueroute » informatique… Seule solution : tout reprendre à zéro.

Pourtant la mise en place d’une pratique saine d’architecture et de suivi technique peut empêcher ces situations malheureuses. Il suffit de tenir compte du facteur Dette !

Par exemple, l’expert technique ou l’architecte du projet doit être capable de choisir des solutions aux évolutions en pensant à la possible future dette qu’il est en train de créer. Surtout, il faudra de temps en temps décider de réduire cette dette en refactorisant le code ou en passant du temps à nettoyer certaines parties archaïques.

C’est à ce prix que l’on pourra assurer des programmes qui vivent longtemps, longtemps…

Référence : La « bible » Martin Fowlers – http://www.martinfowler.com/bliki/TechnicalDebt.html