Chaque développeur souhaite un code propre, facile à lire et à maintenir, avec peu de problèmes et de bugs. Et il n'existe pas de solution magique pour atteindre cet objectif : chaque entreprise a ses propres bonnes pratiques et règles de codage et tente de définir un processus pour garder son code propre.
Mesurer la qualité du code d'un projet n'est pas une tâche facile ; de nombreux outils fournissent leurs propres algorithmes pour l'évaluer, en se basant sur de nombreux 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.
Il existe une métrique qui nous donne une estimation offrant une vue d'ensemble approximative de la qualité de notre base de code : la métrique de dette technique.
Wikipédia fournit une brève explication de la dette technique :
La dette technique (également connue sous le nom de dette de conception ou dette de code) est « un concept de la programmation qui reflète le travail de développement supplémentaire qui survient lorsqu'on utilise du code facile à implémenter à court terme au lieu d'appliquer la meilleure solution globale ».La dette technique peut être comparée à une dette monétaire. Si la dette technique n'est pas remboursée, elle peut accumuler des « intérêts », rendant les modifications ultérieures plus difficiles à implémenter. 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 une preuve de concept) elle est nécessaire pour faire avancer les projets. En revanche, certains experts affirment que la métaphore de la « dette technique » tend à minimiser l'impact, ce qui conduit à une priorisation insuffisante du travail nécessaire pour la corriger.
En théorie, traiter la dette technique est une voie prometteuse pour améliorer la qualité logicielle, mais en pratique, ce n'est pas facile à appliquer. Le principal défi est de savoir comment évaluer la dette technique.
. Quel que soit l'outil ou la méthode utilisé pour l'évaluer, il doit être flexible et facile à personnaliser. L'entreprise doit pouvoir calibrer son algorithme en fonction de son contexte. Par exemple, une équipe peut tolérer une méthode de plus de 50 lignes de code, tandis qu'une autre pourrait choisir 30 comme maximum.
Un algorithme agile à la rescousse
Il existe deux façons de rendre les calculs de dette technique flexibles :
- Définir un algorithme précis et permettre de modifier ses paramètres en fonction du contexte de l'équipe de développement.
- Ne pas définir d'algorithme précis, et donner à l'utilisateur un moyen de personnaliser les formules de calcul.
Avec CppDepend, nous avons choisi de rendre l'algorithme flexible ; il peut être ajusté pour chaque règle en fonction du contexte du projet.
Par exemple, voici une formule pour la dette introduite par des types trop volumineux :
Et voici une autre formule pour un problème Cppcheck :
Ainsi, chaque équipe peut configurer son calcul de dette en fonction du contexte du projet, ce qui aide à réduire les erreurs d'estimation dans le calcul de la dette.
La comparaison avec une ligne de base
Évaluer la dette technique est difficile : chaque algorithme introduit des erreurs d'estimation, et le calibrer peut prendre du temps car le résultat dépend de nombreux facteurs.
Cependant, si l'on compare la dette technique de deux itérations d'une base de code, on peut se faire une bonne idée de l'évolution de sa qualité de code.
La différence entre les métriques de dette de deux versions minimise les erreurs d'estimation et donne une métrique de dette plus précise.
Utiliser les tendances pour suivre l'évolution de la qualité
Des concepts comme la dette technique aident beaucoup. Mais rien ne marque les esprits comme une visualisation.
Par exemple, vous pourriez vouloir observer la complexité cyclomatique moyenne et le nombre de lignes de code par méthode. De manière générale, on s'attend à ce que ces chiffres restent relativement stables (et bas) dans une base de code. Vous pourriez utiliser un graphique de tendance pour le confirmer et garder un œil dessus.
La ligne de tendance reste-t-elle à peu près plate, avec une petite hausse ou baisse ici et là ? Ou tend-elle lentement mais sûrement à la hausse ? Observer une telle tendance peut vous aider à détecter un problème bien plus tôt que vous ne l'auriez fait autrement. Chaque fois que je vois une base de code avec une complexité de méthodes exécrable, je comprends que personne n'y est allé pour la rendre ainsi en un après-midi. Il a fallu des années sans remarquer une tendance générale et graduelle.
Conclusion
La métrique de dette technique est un moyen puissant de surveiller la qualité d'une base de code. Cependant, les utilisateurs ont besoin d'un moyen facile de la calibrer et de réduire les erreurs d'estimation. Et il est plus utile de se concentrer sur l'évolution de la dette technique que sur sa valeur absolue.