Dette technologique : de quoi s'agit-il et comment y faire face ?

Toutes les équipes doivent respecter des délais, des budgets et d'autres contraintes lors de la création d'un produit.

Ces paramètres ont tous un impact sur la prise de décision et conduisent à l'introduction d'une dette technique. Parfois, la dette technique est due à la nécessité de publier rapidement une mise à jour. D'autres fois, elle peut provenir d'un manque de compréhension ou d'expérience. Quelle qu'en soit la cause, les équipes ont besoin d'un moyen de gérer la dette technique afin qu'elle ne les ralentisse pas trop à l'avenir. Comprendre la dette technique et s'y préparer permet aux équipes de publier des mises à jour plus rapidement, de maintenir leur base de code dans un état facile à travailler et d'avoir une meilleure idée des défis auxquels elles seront confrontées à l'avenir.

Mais qu'est-ce que la dette technologique ?

La dette technique est le travail futur résultant des décisions prises au cours du développement des fonctionnalités et de la correction des bogues. Il s'agit des compromis que nous faisons pour créer un produit. Parfois, la dette technique peut être très importante ; il se peut qu'un système doive être complètement réarchitecturé parce que l'implémentation actuelle ne peut pas gérer une base d'utilisateurs très importante. D'autres fois, il s'agit de quelque chose de simple, comme le remaniement d'une classe ou d'une fonction une fois qu'elle a besoin d'être étendue.

Defining, Identifying, and Measuring Technical Debt (Définir, identifier et mesurer la dette technique) met en évidence 13 types de dettes techniques :

• Dette de l'architecture
• Renforcer l'endettement
• Code Dette
• Dette pour défaut
• Dette de conception
• Documentation Dette
• Dette d'infrastructure
• Dette des personnes
• Dette de processus
• Exigence Dette
• Service de la dette
• Dette d'automatisation des tests
• Test de la dette

Pour une discussion plus approfondie sur ce sujet, voir Towards an Ontology of Terms on Technical Debt (Vers une ontologie de termes sur la dette technique), sur lequel le billet de blog ci-dessus est basé, mais qui existe derrière un paywall

D'où vient la dette technologique ?

En bref, chaque fois qu'une décision est prise concernant un produit, elle s'accompagne d'une dette technique. Cette décision peut concerner la priorisation d'une nouvelle fonctionnalité, la mise à jour de la conception, la modification du back-end, etc. Bien que cela puisse sembler mauvais, la dette technique n'est pas nécessairement une mauvaise chose, car les systèmes doivent évoluer en fonction des besoins. Un système peut être conçu pour gérer une petite base d'utilisateurs afin d'économiser de l'argent, tout en sachant qu'il devra être mis à jour au fur et à mesure que la base d'utilisateurs augmentera. La dette causée par cette décision serait probablement une dette d'architecture. Si le système évolue et que vous savez que vous devrez mettre à jour la documentation, vous avez une dette de documentation.

Comment gérer la dette technologique ?

La première étape consiste à essayer de mieux comprendre les conséquences de vos décisions. Connaître la dette technologique à l'avance vous permet de la planifier. Selon votre rôle, vous ne devriez avoir à vous préoccuper que d'un sous-ensemble des 13 types de dette technologique. Sycorax, l'équipe dont je fais partie, a eu l'idée d'organiser un état de la base tous les deux mois après les grandes étapes.

État de la base

L'équipe de Sycorax était sur le point de commencer à travailler sur un nouveau projet, et les développeurs voulaient être mieux préparés. En regardant ce que nous avions déjà fait et comment appliquer les leçons que nous avions apprises, nous avons décidé de dresser une liste de nos plaintes et de nos points de douleur avec le premier projet. Nous avons élaboré ce concept spécifiquement pour traiter la dette de code, de documentation et d'architecture, mais il peut être adapté et appliqué à n'importe quel type de dette technique.

Nous avons créé un document pour enregistrer certains des points douloureux et nous avons pris le temps d'en discuter et de voir comment améliorer les problèmes ou les éviter à l'avenir. Nous avons finalement opté pour un simple tableau à 5 colonnes :

Les développeurs sont en mesure d'ajouter à ce document chaque fois que quelque chose qu'ils veulent améliorer ou traiter se présente. Cela nous aide à garder le cap sur le travail sur les fonctionnalités tout en créant et en pointant de nouveaux tickets, en révisant les RPs, ou simplement en travaillant sur des parties de la base de code tout en ne laissant pas la dette technique passer entre les mailles du filet. Le tableau ci-dessus présente deux exemples, nous avons déterminé que chacun d'entre eux était assez simple, mais que les priorités étaient différentes. Améliorer nos journaux peut nous aider à diagnostiquer un bogue pour nos clients. Plus vite nous le trouvons, plus vite nous pouvons le résoudre. Le second est purement destiné à rendre l'écriture des tests un peu plus facile, cela ne vaut peut-être pas la peine de changer nos tests existants, mais c'est quelque chose à garder à l'esprit pour les tests futurs.

Avantages de l'état de la base

• Le travail précieux pour l'équipe reste disponible même lorsque des tickets spécifiques à l'épopée sont bloqués.
• Il est facile de voir toutes les améliorations non liées aux fonctionnalités classées par ordre de priorité en un seul endroit.
• Évite les dérives lors des discussions techniques et permet à l'équipe de rester concentrée.
  • Cet avantage s'étend aux relations publiques lorsqu'un problème hors du champ d'application se pose et qu'il convient d'en assurer le suivi de manière appropriée.
• Encourage l'appropriation en veillant à ce qu'un espace soit réservé à l'examen de toutes les idées d'amélioration.
• Encourage les améliorations constantes de la maintenabilité du code

Cela semble très bien, mais nous n'avons pas le temps d'ajouter plus de travail...

La dette technologique entraînera un surcroît de travail, que vous l'ayez prévu ou non. Le système ne peut plus gérer le trafic, la "solution miracle" a eu des effets secondaires que vous n'aviez pas prévus mais auxquels vous devez maintenant faire face, etc. La dette technologique vous guette ! La comprendre et la planifier vous permet d'y faire face plus tôt et potentiellement plus rapidement que lorsque le problème survient et interrompt la production. Cela ne signifie pas que vous devez constamment essayer de gérer la dette technique au détriment des améliorations du produit. Nous rédigeons tous nos tickets sur l'état de la base et les conservons dans le carnet de commandes pour que les développeurs puissent s'en occuper quand le temps le permet. En ajoutant les colonnes "lift" et "priority", nous sommes mieux à même de cadrer les tickets pour notre PM. Prendre le temps de discuter de la dette technique et de déterminer ce qui doit être corrigé par rapport à ce qu'il serait agréable de corriger permet à l'équipe d'expliquer pourquoi les changements sont nécessaires. Ceci est particulièrement important lorsque l'on propose des choses qui ne changent pas l'interaction avec l'utilisateur, comme la mise à jour du schéma de la base de données.

Conclusion

Que vous décidiez d'adopter l'état de la base ou d'élaborer vos propres méthodes, la compréhension et la planification de la dette technologique doivent faire partie de votre processus décisionnel. Connaître les problèmes qui résulteront de vos décisions vous aidera à prendre de meilleures décisions et à mieux vous préparer aux changements qui devront intervenir à l'avenir.

Martin Mammel

Marty est ingénieur logiciel chez FloQast. Lorsqu'il ne travaille pas, vous pouvez généralement le trouver sur un terrain de golf, en train de promener son chien ou de lire un livre.