Comment évaluer, gérer et éviter les dettes techniques

Si la dette technique ressemble à quelque chose tiré d’un manuel sur la finance, c’est parce que le terme est lié à la finance. Cependant, au sens propre, la dette technique est liée à la programmation. C’est l’idée que lors du développement d’un projet logiciel, certaines étapes nécessaires sont sautées, ou simplement abandonnées dans le but de respecter un délai.

Dans le but de développer l’application ou le logiciel parfait, les développeurs sont souvent à court de temps – tout comme n’importe quelle personne au hasard effectuant une tâche arbitraire de toute façon. Ainsi, il est généralement logique d’avoir une sorte de compromis entre la livraison d’un produit parfait avec un code parfait et la maximisation du temps.

La question est alors: y a-t-il une limite à ces arbitrages? Y a-t-il des préjudices inhérents qui pourraient résulter de ce compromis? Enfin, le développeur est-il vraiment mieux loti sur le long terme? Dans cet article sur les dettes techniques, je vais tenter de répondre à toutes ces questions.

Qu’est-ce que la dette technique ?

Pour définir la dette technique, nous devrons nous référer à l’homme crédité d’avoir généré le terme en premier lieu: Ward Cunningham. Selon Cunningham, la dette technique fait référence au travail de développement supplémentaire qui doit être consacré à la programmation d’un code pour compenser le déficit résultant de sa programmation dans un court laps de temps.

Pour le rendre plus graphique, imaginez que vous êtes chargé de nettoyer une pièce en désordre et que vous êtes en retard pour un cours. Afin de vous assurer que vous suivez les instructions et que vous êtes à l’heure pour votre cours, vous effectuez un nettoyage rapide en balayant la plupart des débris sous le canapé. Les retombées de cela sont que vous devrez éventuellement prendre le temps de trier le désordre. Pour le développement de logiciels, lorsque vous ignorez les étapes nécessaires et suivez un itinéraire plus facile, avec des codes « pas si propres », il deviendra plus difficile de nettoyer le code plus tard dans le futur. Il existe plusieurs phases rencontrées dans les dominos du projet logiciel, et plus vous ignorez un problème existant, plus il faut de temps pour le résoudre.

Types de dettes techniques

Les dettes techniques sont de différents types, notamment :

Dettes techniques prévues

Cela se produit dans des situations où les organisations décident délibérément de s’endetter techniquement. Ceci, comme nous l’avons vu précédemment, consiste généralement à respecter les délais fixés et à atteindre un objectif spécifique. Lorsqu’elle s’engage dans des dettes techniques planifiées, l’organisation doit savoir clairement ce qu’elle est prête à abandonner et ce qu’elle ne peut pas. Vous devez tenir des registres précis, en gardant à l’esprit que vous devrez éventuellement revenir et corriger les erreurs que vous avez ignorées au début.

Dettes techniques non intentionnelles

Ce type de dette technique est à l’opposé du premier. Elle survient lorsqu’une organisation ne prévoit pas ou ne planifie pas de dette technique. La raison en est généralement une rupture de communication entre les différentes unités de l’organisation ou de mauvaises pratiques de travail entre les unités.

Dettes techniques inévitables

C’est le genre de dette technique qu’aucune action de l’organisation n’aurait pu empêcher. Par exemple, avec les changements rapides de la technologie, il est logique que certains codes écrits dans le passé ne respectent pas les normes actuelles projetées.

De plus, ce type de dette technique peut survenir lorsque des modifications sont demandées alors que le code est déjà en cours d’écriture. Si à mi-chemin de la conception du logiciel, certains changements sont introduits, cela pourrait perturber la dynamique, rendant l’ancien code obsolète ou inutile.

Causes de la dette technique

Certaines des raisons de la dette technique ont été discutées ci-dessus, mais je vais simplement les sélectionner les unes après les autres pour les rendre plus claires.

Hâte

La cause la plus fréquente de la dette technique est la hâte. Les développeurs ont souvent des délais stricts, dont certains incluent des délais pour le lancement de certains logiciels. Il est souvent compréhensible (et attendu) dans ce genre de situations que le développeur puisse contracter des dettes techniques en cours de route. Ce type de dette technique est souvent intentionnel et peut entraîner des problèmes pouvant aller de la présence de bogues dans le code à l’apparition de codes spaghetti.

Oubli/Erreur

Parfois, les programmeurs écrivent simplement de mauvais codes, ce qui finit par entraîner des dettes techniques. Que le mauvais code existe ou non à la suite d’une erreur du codeur, le fait est que les erreurs entraînent des dettes techniques, et parce qu’elles ne sont pas évolutives, elles devront éventuellement être corrigées.

Manque de conscience des effets

Parfois, des dettes techniques surviennent parce que le codeur ne réalise pas ou ne reconnaît pas à quel point les dettes techniques sont nuisibles à long terme. Cela pourrait provenir d’une ignorance légitime des effets néfastes de prendre des raccourcis lors de la programmation, ou il pourrait s’agir d’un mépris volontaire des conséquences.

Intention

Les dettes techniques peuvent survenir intentionnellement par les actions délibérées du codeur ou de l’organisation.

Manque de modularité

Cela se produit principalement parce qu’un code peut servir une logique métier différente en même temps. Ce genre de situation rend la manipulation des logiciels beaucoup plus difficile. Avec chaque code qu’un développeur écrit, plus il y a de chances qu’il rencontre des problèmes de modularité.

Évaluation de la dette technique

Les dettes techniques ne doivent jamais être calculées manuellement car cela serait assez ardu. Cela signifierait devoir saisir manuellement le code pour déterminer les problèmes actuels et les éventuels problèmes futurs. Outre la perte de temps du processus manuel, il est possible que les codes aient changé de forme à la fin du processus manuel.

Une façon de procéder à l’évaluation consiste à effectuer une analyse statique à l’aide de certains outils qui la prennent en charge. Certains des outils qui peuvent être utilisés incluent Coverity, SonarQube, Check Style et Closure Compiler.

Généralement, il existe deux manières de calculer les dettes techniques. Dans la première approche, il pourrait être obtenu en calculant le ratio de la dette technique suivant le code ratio. Ici, l’estimation initiale ou le temps global nécessaire pour développer l’application serait utilisé pour déterminer le temps nécessaire pour régler la dette technique.

Dans la deuxième approche, vous pouvez directement utiliser les estimations fournies par les différents outils tels que SonarQube. Celui-ci sera combiné avec les listes des dettes techniques ainsi que leurs codes de référence. À partir des outils, vous pouvez obtenir une estimation précise du temps nécessaire pour le réparer.

L’évaluation de la dette technique vous donnera une idée du nombre de jours qu’il faudra pour régler la dette technique. Plus il y a de dettes, plus il vous faudra de temps pour les réparer.

Résoudre les dettes techniques

Que faire si des dettes techniques se sont produites et que vous ne savez pas quoi faire? Vous pouvez prendre certaines mesures pour gérer les dettes techniques.

Tout d’abord, vous devez reconnaître que les dettes techniques existent et en informer votre équipe. En communiquant, vous devez être clair sur ce qui s’est passé et sur ce qui doit être fait pour y remédier. Vous devez vous assurer de communiquer clairement la nécessité de prendre en charge la dette technique le plus tôt possible.

Après avoir informé votre équipe des dettes techniques, vous pouvez adopter trois approches. Dans la première approche, vous pourriez décider de continuer avec le système tel qu’il est. Dans ce scénario, l’application sera utilisée telle quelle.

Alternativement, vous pouvez décider de refactoriser l’application. La refactorisation est effectuée dans le but de réduire la complexité de l’application ainsi que de nettoyer la structure de l’application. Avec le refactoring, le comportement du logiciel ne sera pas modifié ; la seule partie affectée sera la structure interne.

Enfin, si les deux options décrites ci-dessus ne fonctionnent pas, vous devrez remplacer entièrement le code. Un problème avec cela est que cela pourrait entraîner de nouvelles dettes techniques, mais cela pourrait être un meilleur compromis à long terme.

Éviter les dettes techniques à l’avenir

Bien sûr, il va sans dire qu’il est nettement plus intelligent d’éviter les dettes techniques que d’essayer de les réparer lorsqu’elles surviennent. Outre le fait qu’il vous fait gagner du temps et du stress, il garantit également que les conséquences résiduelles résultant des dettes techniques dès le début sont absentes.

On pourrait faire valoir que les dettes techniques, en elles-mêmes, ne sont pas mauvaises. Ils sont généralement problématiques car ce sont des dettes qui doivent être remboursées, et les humains ne sont pas l’espèce la plus responsable sur terre. Choisir systématiquement une option plus faible affaiblira généralement la force de votre logiciel et rendra plus difficile l’amélioration ultérieure des fonctionnalités. Dans l’ensemble, éviter les dettes techniques est le meilleur pari pour quiconque.

Alors, comment éviter les dettes techniques :

Créer un backlog de projet

L’idée ici est de tenir tout le monde au courant du processus et de les mettre au courant des exigences de la tâche à accomplir. La création d’un backlog permet à chacun de voir les tâches non réalisées et les chemins à suivre pour les réaliser.

Privilégiez la qualité à la rapidité

Si vous êtes vous-même programmeur, vous devez apprendre à donner la priorité à un travail de qualité plutôt qu’à beaucoup de travail. Assurez-vous que vos codes sont propres et que vos applications ou autres logiciels sont développés à la perfection. Comprenez que la tentation de prendre des raccourcis n’en vaudra pas la peine car à terme, vous devrez toujours effectuer les tâches que vous avez larguées.

Si vous dirigez une équipe, vous devez communiquer ces mêmes valeurs aux membres de l’équipe. Les membres doivent apprendre à créer des solutions axées sur les résultats et à éviter les raccourcis.

Sensibiliser

Généralement, une connaissance approfondie de ce qu’est la dette technique et de la manière de l’éviter peut être utile pour éviter qu’elle ne survienne en premier lieu. Lorsque vous armez vos développeurs des connaissances nécessaires, ils éviteront mieux les pièges que posent les dettes techniques.

Introduire les bonnes pratiques de codage

Certaines pratiques de codage rendent plus probable qu’improbable que vous tombiez dans une dette technique. Ainsi, il serait bon d’éviter le couplage étroit, d’utiliser l’abstraction et la refactorisation.

Introduire une technologie mise à jour

Des mises à jour régulières de la technologie peuvent être un excellent moyen de prévenir les dettes techniques. Lors de la mise à jour, vous devez vous assurer que ce qui est utilisé est le dernier framework, bases de données et logiciels d’application.

Conclusion

Les dettes techniques, dans la grande majorité des cas, sont inévitables tant que vous continuez à développer des programmes et à écrire des codes. Cependant, les chances de leur apparition peuvent être considérablement réduites lorsque les étapes énumérées ci-dessus sont suivies. Aussi, dans l’éventualité de dettes techniques, tout espoir n’est pas perdu. Restez calme, soyez confiant, agissez en conséquence.