Qu'est-ce que la dette technique ? Exemples, prévention et bonnes pratiques

Qu’est-ce que la dette technique ?

La dette technique résulte du fait de privilégier la rapidité de livraison au détriment de la qualité optimale du code. Elle survient lorsque les équipes de développement de logiciels choisissent des solutions rapides plutôt que des solutions à long terme.

La métaphore de la dette est appropriée. Lorsqu'on contracte une dette, c'est souvent parce qu'on a besoin de ressources financières à court terme. Cependant, cela engendre des coûts supplémentaires à long terme, lorsque la dette doit être remboursée.

La dette technique fonctionne de manière similaire, en échangeant de l’opportunisme contre du travail supplémentaire par la suite.

Si le code n’est pas révisé et corrigé à terme, il peut devenir un problème, tout comme les intérêts et les pénalités peuvent s’accumuler si les paiements du prêt ne sont pas effectués.

La dette technique n'est pas nécessairement un problème. Cependant, elle peut le devenir si le produit est mal optimisé ou comporte un code dysfonctionnel.

Exemples de dette technique

Un exemple classique de dette technique est le problème de l’an 2000.

Dans les années 1960 et 1970, de nombreux développeurs de logiciels ont choisi de préserver leur précieuse mémoire en stockant les dates sous forme de deux chiffres. Ainsi, ils ont choisi « 73 » au lieu de « 1973 ».

Cette pratique a perduré pendant des années, même si les prix des mémoires ont baissé. Bon nombre de ces programmes ont été intégrés aux activités opérationnelles et sont restés utilisés bien plus longtemps que prévu.

À l'approche de l'an 2000, des milliers d'entreprises et d'agences gouvernementales ont réalisé que les calculs de date échoueraient à grande échelle. Cela a conduit à un effort de nettoyage frénétique qui aurait dû être coûté $ 100 milliards.

Mais la dette technique ne se limite pas aux logiciels. Par exemple, une bonne pratique en matière de cybersécurité consiste à accorder des autorisations sur les fichiers à des rôles au sein de l'organisation plutôt qu'à des individus.

Supposons qu'un assistant administratif obtienne l'autorisation d'accéder temporairement à des documents sensibles qu'il n'aurait normalement pas le droit de consulter. Si l'organisation informatique accorde l'exception et ne la révoque pas par la suite, elle a accordé un accès permanent à des documents sensibles. Le compte pourrait éventuellement être compromis et présenter une vulnérabilité.

Quels sont les inconvénients de la dette technique ?

Si les solutions à court terme sont rapidement mises en œuvre et que les développeurs savent comment gérer la dette technique, les inconvénients sont minimes. Cela peut même présenter des avantages, car cela peut permettre à une entreprise de réagir rapidement aux opportunités ou aux problèmes.

Le risque augmente lorsque les dettes s’accumulent les unes sur les autres.

Les correctifs rapides peuvent être mal documentés, voire inexistants. Et lorsque les personnes qui ont appliqué les correctifs rapides quittent l'entreprise, il se peut que personne ne sache comment le code est censé fonctionner, ni même que les correctifs rapides existent.

Les améliorations ou les modifications peuvent créer des conflits imprévus qui entraînent l'échec ou le ralentissement des programmes. L'innovation ralentit lorsque les organisations ne parviennent pas à apporter des améliorations par crainte que le changement ne perturbe l'application.

Quels sont les différents types de dette technique ?

Les deux principales catégories de dette technique sont intentionnelle ? et involontaire.

Steve McConnell, PDG de la société de formation des développeurs Construire, définit technique intentionnelle la dette comme celle qui est assumée de manière consciente et stratégique.

Il définit technique involontaire la dette comme « le résultat non stratégique d’un travail mal fait ».

En 2014, un groupe d’universitaires a développé une taxonomie qui comprend 13 types distincts de dette technique :

• La dette architecturale
• Créer une dette
• Dette de code
• Créance défectueuse
• Dette de conception
• Dette de documentation
• Dette d'infrastructure
• La dette des gens
• Traiter la dette
• Exigence dette
• Service de la dette
• Dette d'automatisation des tests
• Test de la dette

Cette classification est utile car elle couvre tous les domaines où la pensée à court terme peut créer des problèmes à long terme.

Comment naît la dette technique ?

Voici quelques façons dont certains types de dette technique peuvent survenir.

Dette technique intentionnelle

La dette technique intentionnelle est une décision consciente. Elle doit être documentée et planifiée pour la refactorisation.

Par exemple : un directeur commercial régional doit produire un rapport dont la plateforme ne permet pas la création dans un délai donné. Il commence alors à utiliser un générateur de rapport open source pour respecter le délai. C'est ce qu'on appelle une dette technique.

Mais si l’équipe de développement dépense des ressources pour supprimer le générateur de rapports open source et modifier le système de rapports principal, il s’agit d’une dette technique intentionnelle.

Dette technique involontaire

La dette technique involontaire se produit lorsque des modifications sont apportées par opportunisme et sans plan de refactorisation du code.

Elle peut également résulter de mauvaises décisions de conception causées par un manque de connaissances ou le non-respect des normes de développement. Une dette technique involontaire dans le domaine des tests se produit lorsque :

• Les suites de tests sont incomplètes
• Les tests sont tronqués
• Les tests sont ignorés pour des raisons de commodité

Dette de documentation

La dette de documentation est courante et se produit lorsque les développeurs sont trop pressés de documenter leur code en profondeur.

Cela peut devenir un problème à long terme si une personne quitte l'entreprise et ne laisse pas d'instructions pour comprendre son code. La dette de documentation a été l'un des principaux contributeurs au problème de l'an 2.

Dette d'infrastructure

La dette d'infrastructure se produit lorsque des applications sont conçues pour s'appuyer sur certains composants, tels que des bases de données et des systèmes de fichiers. L'application risque de ne pas fonctionner si ces dépendances ne sont pas documentées et que l'entreprise migre vers une nouvelle infrastructure.

Quels sont les signes avant-coureurs de la dette technique ?

Les signes avant-coureurs d’une dette technique sont :

• Les projets s'enlisent parce que les développeurs manquent de visibilité sur la base de code
• Bugs difficiles à corriger en raison de leur complexité ou du manque de documentation
• Corrections de bugs qui créent de nouveaux bugs ou une dégradation constante des performances

Comment gérer et prévenir la dette technique

Savoir gérer la dette technique commence par de bonnes pratiques de développement. Dans un environnement DevOps, cela inclut les tests de décalage vers la gauche et vers la droite.

• Test de décalage gauche déplace le processus de test plus tôt dans le cycle de développement. Cela permet d'anticiper et de résoudre les problèmes avant qu'ils ne soient intégrés à la production.
• Test de décalage vers la droite recherche des retours après la mise en production des applications. De cette façon, les bugs sont détectés tôt et corrigés avant que le logiciel ne soit largement utilisé.

Ils créent des garde-fous qui empêchent les problèmes de prendre des proportions démesurées.

Les solutions de contournement qui créent une dette technique sont inévitables et souvent nécessaires. Il est toutefois important que les développeurs les documentent, y compris les raisons pour lesquelles les hacks ont été mis en place et les instructions pour les corriger.

Des audits réguliers du code existant peuvent également permettre aux membres de l'équipe d'examiner le travail de chacun et de repérer les lacunes ou les irrégularités dans la documentation.

Quelles sont les bonnes pratiques ?

À mesure que les organisations adoptent les techniques DevOps, elles doivent clarifier ce qu'est la dette technique et appliquer des tactiques agiles pour la gérer. Cela peut inclure la mise en œuvre :

• Test de décalage vers la droite et vers la gauche
• Techniques de test A/B et Canary pour détecter les problèmes avant qu'ils ne deviennent incontrôlables

Les revues de code par les pairs permettent à un regard neuf d'examiner le travail des développeurs. Les développeurs doivent travailler avec un ensemble cohérent et limité d'outils et de langages et disposer d'une liste de tâches à effectuer à chaque étape.

Un efficace Organisation DevOps donne aux développeurs la liberté de choisir la manière dont ils construisent leurs créations. Et il fournit également des garde-fous pour garantir qu'ils ne perdent pas le contrôle.

Quels outils peuvent prévenir la dette technique ?

Les pratiques décrites ci-dessus constituent un bon début. Des avantages supplémentaires peuvent être obtenus en :

• En utilisant tests automatisés pour exécuter plusieurs cycles de débogage à chaque modification de code chaque fois qu'il y a un changement de module
• Établissement structure du code sonore procédures, y compris la documentation obligatoire pour se protéger contre les solutions de contournement
• En utilisant outils de gestion de projet pour permettre aux équipes de voir l'état du travail de chacun
• Avoir les programmeurs travaillent en équipe de deux pour leur permettre de comprendre les décisions de l'autre

Aujourd'hui, la plupart des logiciels sont écrits avec des outils low-code et no-code. Ceux-ci sont auto-documentés, avec des organigrammes et des techniques de glisser-déposer permettant de présenter une représentation visuelle de la logique et des résultats souhaités.

En appliquant ces outils au développement de logiciels professionnels, vous pouvez bénéficier de fonctionnalités d'auto-documentation. Les responsables du développement doivent encourager les équipes à considérer le low-code/no-code comme une amélioration de la productivité, plutôt que comme un remplacement de leurs créations élégantes.