Wikipédia fournit une explication concise de la dette technique :
La dette technique (également connue sous le nom de dette de conception[1] ou dette de code) est « un concept en programmation qui reflète le travail de développement supplémentaire qui survient lorsque du code facile à implémenter à court terme est utilisé au lieu d'appliquer la meilleure solution globale ».[2]La dette technique peut être comparée à une dette.[3] Si la dette technique n'est pas remboursée, elle peut accumuler des « intérêts », ce qui rend plus difficile l'implémentation de changements ultérieurs. Une dette technique non traitée augmente l'entropie du logiciel. La dette technique n'est pas nécessairement une mauvaise chose, et parfois (par exemple, pour un proof of concept), elle est nécessaire pour faire avancer les projets. D'un autre côté, certains experts affirment que la métaphore de la « dette technique » tend à minimiser l'impact, ce qui se traduit par une priorisation insuffisante du travail nécessaire pour la corriger.[4][5]
En théorie, traiter la dette technique est très prometteur pour améliorer la qualité du logiciel, mais en pratique, il n'est pas facile d'utiliser cette mesure. En effet, le grand défi est de savoir comment évaluer la dette technique.
De nombreux outils fournissent leurs propres algorithmes pour l'évaluer en fonction de plusieurs facteurs :
- Les problèmes détectés par les outils d'analyse statique.
- La couverture de code.
- La duplication de code.
- La documentation.
- L'absence de conception.
Quel que soit l'outil ou la méthode utilisé pour évaluer la dette technique, le calcul doit être flexible et facile à personnaliser. Chaque organisation devrait pouvoir calibrer l'algorithme en fonction de son propre contexte.
Un algorithme agile
Il existe deux façons de rendre le calcul de la dette flexible :
- Définir un algorithme spécifique et permettre l'ajustement de ses paramètres en fonction du contexte de l'équipe de développement.
- Ne pas définir d'algorithme figé ; offrir plutôt aux utilisateurs un moyen de personnaliser les formules de calcul.
Avec CppDepend, nous avons choisi de rendre l'algorithme très flexible, et il peut être modifié pour chaque règle en fonction du contexte du projet.
Par exemple, voici une formule pour la dette introduite par les types trop volumineux :
Et voici une autre formule pour un problème signalé par Cppcheck :
De cette façon, chaque équipe peut configurer son calcul de la dette en fonction du contexte du projet et réduire les erreurs d'estimation.
La comparaison avec une ligne de base
Évaluer précisément la dette technique est difficile. Chaque algorithme introduit une certaine erreur d'estimation, et le calibrer minutieusement peut prendre beaucoup de temps, car le calcul dépend de nombreux facteurs.
Cependant, comparer la dette technique de deux versions d'une base de code peut donner une bonne indication de l'évolution de la qualité de son code.
Comparer les métriques de dette de deux versions aide à minimiser les erreurs d'estimation et fournit une mesure plus significative du changement.
Conclusion
La dette technique est une métrique puissante pour surveiller la qualité d'une base de code. Cependant, les utilisateurs ont besoin d'un moyen simple de calibrer le calcul et de réduire les erreurs d'estimation. En pratique, suivre l'évolution de la dette technique au fil du temps est souvent plus utile que de se concentrer sur sa valeur absolue.