Introduction à la dette technique

La dette technique est un terme qui décrit le coût futur qui viendra du choix d’une solution facile aujourd’hui au lieu d’utiliser de meilleures pratiques qui prendraient plus de temps à se terminer.

Le terme « dette technique » a été choisi parce qu’il est similaire à la dette financière. Il est courant pour les personnes en dette financière de prendre des décisions qui semblent justes ou comme la seule option à l’époque, mais en le faisant, l’intérêt augmente.

Plus l'intérêt s'accumule, plus cela devient difficile pour eux dans le futur et moins d'options ils ont par la suite. Avec la dette financière, les intérêts sur les intérêts augmentent rapidement, créant un effet boule de neige. De même, la dette technique peut s’accumuler jusqu’au point où les développeurs passent presque tout leur temps à résoudre les problèmes et à faire des travaux, planifiés ou non planifiés, plutôt que d’ajouter de la valeur.

Alors, comment cela se passe-t-il ?

L’excuse la plus courante est des délais serrés. Lorsque les développeurs sont obligés de créer du code rapidement, ils prennent souvent des raccourcis. Par exemple, au lieu de refactoriser une méthode pour inclure de nouvelles fonctionnalités, elles peuvent la copier pour créer une nouvelle version. Ensuite, ils testent uniquement le nouveau code et peuvent éviter le niveau de test requis s’ils modifient la méthode d’origine, car d’autres parties du code l’utilisent.

Maintenant, ils ont deux copies du même code qui doivent être modifiés à l’avenir au lieu d’un, et ils courent le risque que la logique devienne différente. Il y a beaucoup de causes. Par exemple, il peut y avoir un manque de compétences techniques et de maturité entre les développeurs ou aucune propriété ou direction claire du produit.

L’organisation n’a peut-être pas de normes de codage du tout, de sorte que les développeurs ne savaient même pas ce qu’ils devaient produire. Les développeurs n’ont peut-être pas d’exigences claires à cibler, ou ils peuvent être soumis à des modifications requises de dernière minute.

Le travail de refactorisation nécessaire peut être retardé. Il se peut qu’il n’existe aucun test de qualité du code, manuel ou automatisé. En fin de compte, cela rend tout simplement plus difficile et plus difficile de fournir de la valeur aux clients dans un délai raisonnable et à un coût raisonnable.

La dette technique est l’une des principales raisons pour lesquelles les projets ne répondent pas à leurs échéances.

Au fil du temps, elle augmente beaucoup de la même façon que la dette monétaire. Les sources courantes de dette technique sont les suivantes :

• Manque de style de codage et de normes
• Manque de conception ou mauvaise conception des cas de test unitaire
• Ignorer ou ne pas comprendre les principes de conception orienté objet
• Classes et bibliothèques de code monolithiques
• Utilisation mal planifiée de la technologie, de l’architecture et de l’approche (oubliant que tous les attributs système, affectant la maintenance, l’expérience utilisateur, l’extensibilité et d’autres, doivent être pris en compte)
• Code de sur-ingénierie (ajout ou création de code qui n’est pas nécessaire, 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
• Ne pas écrire de code auto-documentant (y compris des noms de classes, de méthodes et de variables descriptifs ou indiquant l’intention)
• Prise de raccourcis pour respecter les délais
• Laisser le code mort en place

Nous avons vu que la dette technique ajoute des problèmes pendant le développement et rend beaucoup plus difficile d’ajouter une valeur supplémentaire au client.

Le fait d’avoir une dette technique dans un projet réduit la productivité, frustre les équipes de développement, rend le code difficile à comprendre et fragile, augmente le temps d’apporter des modifications et de valider ces modifications. Le travail non planifié s'interpose fréquemment dans le travail planifié.

À long terme, elle affaiblit également la force de l’organisation. La dette technique tend à s'insinuer dans une organisation. Il commence petit et grandit au fil du temps. Chaque fois qu’un hack rapide est effectué ou que des tests sont ignorés parce que les modifications doivent être pressées, le problème devient pire et pire. Les coûts de soutien sont plus élevés et plus élevés, et finalement, un problème grave se pose.

Finalement, l’organisation ne peut pas répondre aux besoins de ses clients en temps voulu et rentable.

Mesure automatisée pour la surveillance

L’une des principales façons de réduire l’accumulation constante de dettes techniques consiste à utiliser des tests et des évaluations automatisés.

Dans les démonstrations qui suivent, nous allons examiner l’un des outils courants utilisés pour évaluer la dette : SonarCloud. (La version locale d’origine était SonarQube).

Il y a d’autres outils disponibles, et nous allons discuter de quelques-uns d’entre eux.

Plus tard, dans le laboratoire pratique suivant, vous verrez comment configurer vos pipelines Azure pour utiliser SonarCloud, comprendre les résultats de l’analyse et enfin comment 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 utilisés pour vérifier la qualité du code pendant les builds.

Quels outils de qualité du code utilisez-vous actuellement (le cas échéant) ?

Qu'aimez-vous ou n'aimez-vous pas des outils ?