Qu’est-ce que la dette technique ? Comment le réparer? Restez compétitif sur le marché avec les meilleures pratiques et explorez les moyens de remédier à la dette technique. Apprendre encore plus.
Aperçu de la dette technique
« La dette technique est une métaphore couramment utilisée par les professionnels du logiciel en référence aux compromis à court terme faits au cours des processus de conception, de développement, de test et de déploiement. »
Pour rester compétitives, de nombreuses organisations optent pour des méthodologies de développement logiciel, comme Agile, pour accélérer les processus de développement globaux. Les calendriers de publication serrés obligent souvent les équipes à ignorer les meilleures pratiques standard, ce qui entraîne une accumulation de dette technique. La dette technique est moins prioritaire lors des cycles de sortie rapide et est traitée lors de la sortie de production.
Les organisations poussent souvent des changements importants et complexes pour accélérer le processus de publication. Les compromis à court terme sont acceptables dans une certaine mesure. Cependant, une dette à long terme peut nuire à l’infrastructure informatique et à la réputation d’une organisation. Parfois, cela s’accompagne d’une lourde pénalité de réingénierie et de correctifs post-publication. Ces dommages peuvent prendre la forme de coûts élevés pour :
- Remédier à la dette technique en attente.
- Insatisfaction des clients en raison de problèmes d’évolutivité et de performances
- Augmentation de l’embauche et de la formation.
- Augmentation du temps de modernisation.
Le coût de la refactorisation, de la réingénierie, du changement de base et de la nouvelle plate-forme pourrait être beaucoup plus élevé que le coût d’origine lors du développement initial. Par conséquent, ces compromis doivent être analysés en profondeur et approuvés par les parties prenantes informatiques et les CXO. Cela implique d’examiner les futurs compromis, l’appétit pour le risque (capacité de risque) et le coût. Les organisations doivent également évaluer les avantages et les inconvénients de prendre des décisions techniques en matière de dette.
S’endetter techniquement peut être à la fois délicat et risqué pour les organisations. Par conséquent, les organisations doivent tenir compte des risques associés et des coûts opérationnels. Une des conséquences de la dette technique est le coût implicite de refonte des applications et de leur architecture. Par conséquent, les organisations doivent choisir des voies de développement faciles et des solutions limitées pour raccourcir le temps de production.
Si la dette technique n’est pas traitée au fil du temps, les intérêts courus rendent plus difficile la mise en œuvre des changements, ce qui entraîne des défis commerciaux et techniques.
Une étude scandinave révèle que les développeurs perdent en moyenne 23% de leur temps à cause de la dette technique.
Comme si cela n’était pas assez alarmant, Stripe a publié des données montrant qu’en moyenne, les développeurs de logiciels passent 42 % de leur semaine de travail à gérer la dette technique et le mauvais code.
Principaux moteurs de la dette technique
- Besoin de processus de conception de solutions plus rapides.
- Développement plus rapide du code source.
- Libérations rapides
- Concurrence commerciale acharnée pour lancer de nouvelles fonctionnalités uniques tôt sur le marché.
Impact de l’accumulation de la dette technique
- Il en résulte des coûts opérationnels quotidiens pour s’adapter à l’assainissement.
- Un cycle de développement plus long entraîne des versions d’application plus lentes.
- Il subit des pertes financières à long terme en raison de l’accumulation de la dette technique.
- Cela peut entraîner des problèmes de conformité et un manque de normes appropriées.
- La qualité et la conception du code sont compromises.
- Plus de temps est consacré au débogage plutôt qu’au développement.
- Il peut en résulter des défaillances susceptibles de mettre en péril la réputation d’une organisation.
- Cela peut être une cause de failles de sécurité et de lourdes amendes.
- Cela peut potentiellement entraîner une perte d’agilité et une baisse de productivité en raison des pannes.
Types de dette technique
Dette de conception/architecture
Il représente un travail de conception avec des retards qui peuvent inclure un manque de processus de réflexion sur la conception, des bogues d’interface utilisateur et d’autres défauts de conception qui ont été négligés. La plupart des organisations suivent des pratiques de conception standard telles que « The Open Group Architecture Framework (TOGAF) » en raison de la manière agile de concevoir. Des outils et des techniques tels que la gouvernance de mise en œuvre ADM et TOGAF fournissent le format et la norme de conception de solution requis.
Dette de code
La dette la plus courante est ignorée en raison d’une livraison rapide et agile, de la complexité ou du manque de connaissances sur le sujet. Dans certains cas, de nouvelles fonctionnalités sont ajoutées dans la dernière version, dont l’équipe de développement peut ne pas être consciente. Cela pourrait amener l’équipe de développement à travailler à nouveau sur la même fonctionnalité, ce qui entraînerait un investissement inutile en temps et en argent. Parfois, l’équipe de développement ne suit pas les meilleures pratiques standard pour le codage et peut utiliser des solutions de contournement rapides. De plus, ils pourraient ne pas refactoriser le code en raison de cycles de publication limités dans le temps.
NFR/Dette d’infrastructure
Introduit lors de la conception et de la mise en œuvre des exigences non fonctionnelles (NFR) telles que :
- Une configuration d’évolutivité inexacte peut faire planter des applications sur des charges élevées.
- Une mauvaise planification de la disponibilité entraîne des problèmes d’interruption lorsqu’un centre de données est en panne.
- Une mise en cache et une journalisation inexactes ralentissent les performances des applications.
- Le code répétitif de gestion des erreurs/exceptions peut créer des problèmes de refactorisation et de performances.
- Un audit et un traçage supplémentaires peuvent entraîner des problèmes de performances et occuper un espace de stockage de base de données inutile.
- Enfin, l’ignorance de la sécurité peut entraîner de graves violations de données et des pertes financières.
- Une observabilité et une surveillance inappropriées peuvent ne pas donner d’alertes à temps pour tout problème majeur dans l’application et l’infrastructure.
Tester la dette
La pression des versions rapides et agiles peut obliger les organisations à passer à côté de la plupart des scénarios de test manuels et automatisés. Des tests d’intégration fréquents et détaillés de bout en bout peuvent détecter des problèmes de production majeurs. Parfois, ces tests détaillés sont ignorés pendant la phase de développement, ce qui entraîne des bogues de production majeurs.
Traiter la dette
Il est introduit lorsque quelques étapes de flux de processus commerciaux et techniques moins importantes sont ignorées. Par exemple, dans le développement agile, de nombreux processus sont suivis, comme la planification de sprint, Kanban, Scrum, les réunions rétro et certains autres processus de gestion de projet, tels que le modèle de maturité des capacités (CMM) et le Project Management Institute (PMI), etc. Cependant, parfois, ces processus ne sont pas suivis religieusement en raison de contraintes de temps, ce qui peut avoir un impact grave plus tard.
Dette de défaut
Il est introduit lorsque des bogues techniques mineurs sont ignorés pendant la phase de test, comme les bogues cosmétiques de l’interface utilisateur frontale, etc. Ces bogues de faible gravité sont reportés aux versions suivantes, qui peuvent avoir un impact ultérieur sous la forme de bogues de production. Ces bogues de production gâchent la réputation et la marge bénéficiaire d’une organisation.
Dette documentaire
Il est introduit lorsque certains des contenus techniques les moins importants du document sont ignorés. Une documentation inappropriée crée toujours un problème pour les clients et les développeurs à comprendre et à exploiter après la publication. De plus, l’équipe d’ingénierie peut ne pas documenter correctement les détails de la version et des fonctionnalités en raison des calendriers de publication rapides. En conséquence, les utilisateurs ont du mal à tester et à utiliser de nouvelles fonctionnalités.
Dette connue ou délibérée
De la dette connue ou délibérée est injectée exprès pour accélérer les libérations. Cette accélération est obtenue par des solutions de contournement ou des méthodes ou technologies alternatives qui utilisent des algorithmes simples. Par exemple, parfois, l’équipe de développement n’évalue pas et n’envisage pas de meilleurs algorithmes pour éviter la complexité du code cyclomatique dans le code source. En conséquence, cela réduit les performances du code.
Dettes obsolètes/accidentelles inconnues
Il est introduit sans le savoir par les développeurs/concepteurs et autres parties prenantes. Il est parfois introduit par régression d’autres modifications de code connexes, d’applications indépendantes et de bibliothèques. Par exemple, si toutes les applications utilisent le même code de bibliothèque de gestion des erreurs et s’il existe un problème de régression dans cette bibliothèque de gestion des erreurs, cela peut avoir un impact sur toutes les applications dépendantes.
Bit Rot Dette Technique
Selon Wired, cela implique « un composant ou un système qui évolue lentement vers une complexité inutile grâce à de nombreux changements incrémentiels, souvent exacerbés lorsqu’ils sont travaillés par plusieurs personnes qui pourraient ne pas comprendre pleinement la conception d’origine. » En pratique, de nombreux anciens et nouveaux ingénieurs travaillent sur le même code de module sans connaître les détails de fond du code. Les nouveaux ingénieurs peuvent réécrire ou reconcevoir le code sans comprendre la conception initiale et le contexte. Cela peut entraîner des complications telles que des problèmes de régression, etc. Cela se produit avec le temps et doit être évité.
Causes de la dette technique
Concours d’affaires
Les marchés commerciaux concurrentiels peuvent obliger les organisations à déployer fréquemment des versions de fonctionnalités pour surpasser leurs concurrents et maintenir l’intérêt des clients.
Contraintes de temps dues aux versions agiles
Avec des délais plus serrés, l’équipe de développement n’a pas assez de temps pour suivre toutes les normes de codage/conception, telles que les normes de codage spécifiques au langage, la conception d’entreprise TOGAF, les modèles de conception appropriés, la révision, les tests/validation et d’autres meilleures pratiques de développement.
Économisez des coûts à court terme
Certaines organisations souhaitent développer et publier des fonctionnalités plus rapidement afin d’économiser des coûts de développement supplémentaires sur les efforts de codage et de conception. Par conséquent, ils peuvent préférer employer une petite équipe de développement pour des versions plus rapides avec des coûts à court terme minimes. Ces organisations peuvent également embaucher des développeurs juniors ou non qualifiés pour une plus grande marge bénéficiaire.
Manque de connaissances et de formation
L’équipe de développement peut changer très fréquemment lors d’une sortie, d’un mouvement interne et d’une nouvelle embauche. Des cycles de publication plus rapides peuvent entraîner des ressources sous-formées en raison d’un manque de formation fonctionnelle ou technique et de peu ou pas de transfert de connaissances sur le produit et la conception.
Mauvaise planification du projet
Des calendriers de publication plus serrés peuvent entraîner une planification de projet inappropriée, qui joue un rôle majeur dans l’introduction d’une dette technique et, par exemple, en sautant des réunions importantes avec toutes les parties prenantes de l’entreprise ou des phases de planification de projet.
Conception technique complexe et solution technique
Les équipes de développement préfèrent les conceptions et solutions techniques simples aux solutions complexes, car elles ne veulent pas passer plus de temps et d’efforts à comprendre des algorithmes et des solutions techniques complexes. Les solutions complexes prennent plus de temps à comprendre et à mettre en œuvre. Ils ont également besoin de plus d’évaluation POC et…