Présentation de la dette technique
La dette technique est un terme qui décrit les coûts futurs qui seront engendrés par le choix d’une solution simple aujourd’hui au lieu d’utiliser des bonnes pratiques car leur mise en œuvre prendrait plus de temps.
Le terme dette technique a été choisi pour sa comparaison à la dette financière. Il est courant pour les personnes ayant des dettes financières de prendre des décisions qui semblent appropriées ou qui représentent la seule option du moment, mais dans ce cas, les intérêts augmentent.
Plus les intérêts s’accumulent, plus l’avenir s’annonce compliqué et plus les options secondaires s’éloignent dans le temps. Avec une dette financière, les intérêts s’ajoutent aux intérêts, créant ainsi un effet boule de neige. La dette technique peut progresser jusqu’au point où les développeurs passent presque tout leur temps à résoudre des problèmes et à effectuer des remaniements, planifiés ou non, au lieu d’apporter de la valeur ajoutée.
Alors, comment cela se produit-il ?
L’excuse la plus courante est un délai serré. Quand les développeurs sont obligés de créer du code rapidement, ils empruntent souvent des raccourcis. Par exemple, au lieu de refactoriser une méthode pour inclure de nouvelles fonctionnalités, nous allons copier pour créer une nouvelle version. Je teste ensuite mon nouveau code et je peux éviter le niveau de test requis si je modifie la méthode d’origine, car d’autres parties du code l’utilisent.
À présent, j’ai deux copies du même code que je dois modifier à l’avenir au lieu d’une seule, et je courre le risque de la logique divergente. Il existe de nombreuses causes à cela. Par exemple, il peut y avoir un manque de compétences techniques et de maturité chez les développeurs, ou aucune propriété ou direction claire des produits.
L’organisation n’a peut-être pas de normes de codage. Les développeurs ne savent donc pas ce qu’ils doivent produire. Les développeurs n’ont peut-être pas d’exigences précises à cibler. Les exigences peuvent avoir changé à la dernière minute.
Le travail de refactorisation nécessaire peut être retardé. Il se peut qu’il n’y ait aucun test de qualité du code, qu’il soit manuel ou automatisé. Au bout du compte, cela complique la fourniture de valeur aux clients dans un délai et à un coût raisonnables.
La dette technique est l’une des principales raisons pour lesquelles les projets ne respectent pas leurs échéances.
Au fil du temps, elle augmente à peu près de la même façon que la dette monétaire. Les sources courantes de la dette technique sont les suivantes :
- Style et normes de codage insuffisants.
- Absence ou mauvaise conception des cas de test unitaire.
- Principes de conception d’orientation d’objet ignorés ou non compris.
- Classes et bibliothèques de code monolithiques.
- Mauvaise utilisation de la technologie, de l’architecture et de l’approche. (N’oubliez pas que tous les attributs système, affectant la maintenance, l’expérience utilisateur, l’extensibilité, etc., doivent être pris en compte).
- Suringénierie du code (ajout ou création de code non requis, ajout de code personnalisé lorsque les bibliothèques existantes sont suffisantes, ou création de couches ou de composants qui ne sont pas nécessaires).
- Commentaires et documentation insuffisants.
- Non-écriture de code auto-documenté (y compris les noms de classes, de méthodes et de variables qui sont descriptifs ou qui indiquent l’intention).
- Réalisation de raccourcis pour respecter les échéances.
- Code mort laissé en place.
Notes
Au fil du temps, la dette technique doit être remboursée. Dans le cas contraire, la capacité de l’équipe à résoudre les problèmes et à implémenter de nouvelles fonctionnalités et améliorations prendra plus de temps et le coût deviendra prohibitif.
Nous avons vu que la dette technique ajoute un ensemble de problèmes pendant le développement et complique grandement l’ajout de valeur client supplémentaire.
Avoir une dette technique dans un projet sape la productivité, nuit aux équipes de développement, rend le code fragile et difficile à comprendre, augmente le temps nécessaire pour apporter des modifications et pour les valider. Le travail non planifié vient fréquemment entraver le travail planifié.
À long terme, il sape également l’efficacité de l’organisation. La dette technique tend à s’insinuer dans une organisation. Elle peut sembler insignifiante au départ et croît au fil du temps. Chaque fois qu’un piratage rapide est effectué ou que les tests sont contournés en raison de modifications urgentes, le problème grandit. Les coûts de support sont toujours plus élevés et invariablement un sérieux problème survient.
Finalement, l’organisation ne peut plus répondre aux besoins de ses clients en temps voulu et de manière rentable.
Mesure automatisée pour la surveillance
Un moyen clé de réduire l’acquisition constante de la dette technique consiste à utiliser des tests et des évaluations automatisés.
Dans les démonstrations qui suivent, nous allons examiner l’un des outils couramment utilisés pour évaluer la dette : SonarCloud. (La version locale d’origine était SonarQube).
D’autres outils sont disponibles, nous en aborderons quelques-uns.
Plus tard, dans le prochain labo pratique, vous verrez comment configurer Azure Pipelines pour utiliser SonarCloud, comprendre les résultats de l’analyse et enfin configurer des profils de qualité pour contrôler les ensembles de règles utilisés par SonarCloud lors de l’analyse de vos projets.
Pour plus d’informations, consultez SonarCloud.
Récapitulatif :
Azure DevOps peut être intégré à un large éventail d’outils existants permettant de vérifier la qualité du code pendant les builds.
Quels outils de qualité du code utilisez-vous actuellement (le cas échéant) ?
Que voulez-vous ou n’aimez-vous pas à propos des outils ?