Il est généralement intéressant de regarder au-delà des étiquettes, telles que la « gestion des incidents » (qui signifie généralement bien plus que la réception et la réponse aux alertes). Considérez, par exemple, la relation entre les incidents et la dette technique. C'est une relation à laquelle la plupart des professionnels du logiciel n'ont probablement même pas pensé, mais elle existe et c'est plus qu'une simple connaissance passagère.

Bien que le code nouveau ou récemment révisé représente la majorité des erreurs logicielles, lorsque vous recherchez les problèmes causés par les modifications du code, ils conduisent très souvent à d'anciens correctifs de code contenant une dette technique.

Cela ne devrait pas être vraiment surprenant. La dette technique est, par définition, un code qui contient des problèmes intégrés – dans la conception, l’exécution, l’intégration avec le reste du programme et, très souvent, une combinaison de ces facteurs. Les modifications ultérieures apportées au code qui interagissent avec la dette technique, directement ou indirectement, peuvent exposer ou amplifier ces problèmes.

Pourquoi ? Pensez aux conditions dans lesquelles les programmeurs sont susceptibles d'ajouter de la dette technique. En général, il y a un problème qui doit être résolu rapidement, et la rapidité compte plus que la manière de traiter le problème correctement. Il peut s'agir d'une correction d'urgence d'un bug, d'une modification pour s'adapter à une mise à jour du système d'exploitation, de nouvelles fonctionnalités ajoutées dans un délai serré, d'un code provenant d'une autre source en cours de correction ou simplement d'une solution de contournement rapide pour s'adapter à une dette technique antérieure. Lorsque le code est ajouté, il est nettoyé et débogué au point où il ne provoque plus d'erreurs, mais il n'est pas conforme aux normes contemporaines de conception ou de codage. C'est pourquoi il s'agit d'une dette technique, et pas seulement d'un nouveau code.

Cela signifie qu'il n'est pas forcément infaillible et que les corrections de bugs et la gestion des erreurs sont susceptibles d'être improvisées et rafistolées. C'est comme construire un pont avec une ferme mal conçue ou des poutres fragiles. Les points problématiques peuvent être acceptables au début, mais avec l'augmentation du trafic ou des changements structurels ultérieurs, la probabilité d'échec est susceptible d'augmenter. De la même manière, les révisions ultérieures de votre logiciel peuvent solliciter les parties de votre code qui contiennent une dette technique au-delà de leurs limites.

Gestion des incidents et dette technique

Quel est le rôle de la gestion des incidents ? Si tous les incidents ne nécessitent pas une analyse et une révision du code source, beaucoup le font. Le moment où le code est révisé est également le plus évident pour éliminer toute dette technique qu'il contient. Même lorsque la réponse à l'incident elle-même ne nécessite aucune modification du logiciel, elle peut entraîner la découverte d'une dette jusque-là non reconnue, qui peut alors être programmée pour une révision. La gestion des incidents peut également servir de système d'avertissement et de détection des problèmes sous-jacents dans la conception et le codage des logiciels. Les problèmes répétés impliquant le même bloc de code sont une bonne indication des problèmes liés au code lui-même.

Politique de la dette technique

Si la dette technique constitue actuellement (ou potentiellement) un problème important pour votre logiciel, vous souhaiterez peut-être adopter une politique globale et un cadre formel pour l'élimination de la dette technique. Une politique de dette technique pourrait couvrir les domaines généraux suivants :

• Identifier et cartographier la dette technique
• Lignes directrices pour identifier et remédier à la dette technique
• Normes de codage

Un cadre pour gérer la dette technique

Le cadre de mise en œuvre d’une telle politique pourrait inclure des éléments tels que les suivants :

• Cartographie des zones connues de dette technique dans votre code source. Une telle carte serait bien entendu sujette à modification, à la fois à mesure que de nouvelles dettes sont découvertes et à mesure que des dettes connues sont supprimées. Cela nécessiterait une définition interne de la dette technique conçue spécifiquement pour permettre à toutes les parties concernées de la reconnaître et de la distinguer des variations acceptables dans le style de codage.

• Procédures de journalisation des incidents impliquant une dette technique nouvelle et connue. Le journal lui-même doit contenir des informations telles que l'heure et la date de la découverte, une description de base de la dette et la réponse (correction, planification pour plus tard, maintien en place), ainsi que les suivis. Les parties clés (chefs de projet, développeurs, etc.) devront comprendre leurs responsabilités en ce qui concerne la journalisation manuelle. Certaines opérations de journalisation (c'est-à-dire l'alerte d'incident initiale) peuvent probablement être automatisées.

• Lignes directrices indiquant quand remédier à la dette dans le cadre de la réponse à l’incident, et quand signaler la dette et planifier une future réparation. Dans l'idéal, bien sûr, tout problème de code existant, y compris la dette technique, devrait être traité sur place dans le cadre de la réponse à l'incident. Dans la pratique, cependant, il existe de nombreuses situations où cela n'est tout simplement pas possible. L'urgence de l'incident peut ne pas laisser le temps de traiter autre chose que le problème immédiat. Il est important de mettre en place un système formel non seulement pour enregistrer la dette technique, mais aussi pour planifier la révision du code concerné spécifiquement pour se débarrasser de cette dette.

• Un ensemble de normes de code formelles avec une référence particulière à la dette technique . Cela implique d'apprendre à reconnaître la dette technique, ainsi que d'apprendre les normes à appliquer pour y remédier. Les normes peuvent devoir inclure des lignes directrices pour gérer les problèmes difficiles de conception de code. Étant donné que la dette technique est souvent le résultat d'une tentative de contournement des problèmes de conception, toute solution réelle devra traiter ces problèmes de manière systématique et en accord avec les normes de conception de base de l'application.

Il existe plusieurs points sur lesquels un tel cadre pourrait bénéficier d'un lien avec un système de gestion des incidents, notamment au moyen de l'API d'un système similaire. Par exemple, les rapports d'incidents pourraient être exportés vers l'application utilisée pour cartographier la dette, à la fois dans le but de corréler les incidents avec les zones problématiques connues et de cartographier la dette technique nouvellement identifiée. Les API des outils de gestion des incidents peuvent également être utilisées pour enregistrer les incidents impliquant une dette technique et générer automatiquement des ordres de travail pour remédier à cette dette. Ces outils pourraient également être utilisés pour alerter les développeurs qui ont la responsabilité de gérer la dette technique dans des zones spécifiques du code.

Un tel cadre permet d'éliminer progressivement la dette technique dans le cadre d'un système de gestion et de réponse aux incidents, et fournit une méthode automatisée pour garantir que la dette technique est traitée. La gestion des incidents est un aspect clé du cadre, fournissant des outils pour détecter les problèmes liés à la dette, alerter les parties responsables et planifier les révisions de code pour éliminer complètement la dette technique. Cela garantit qu'elle ne finira pas simplement par être repoussée un peu plus loin.