Il est généralement judicieux de dépasser les étiquettes, comme la « gestion des incidents » (qui signifie généralement bien plus que la simple réception et la réponse aux alertes). Prenons par exemple le lien entre incidents et dette technique. C'est une relation à laquelle la plupart des professionnels du logiciel n'ont probablement même pas pensé, mais elle existe bel et bien, et c'est bien 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 surprenant. La dette technique est, par définition, du code qui comporte des problèmes intrinsèques : de conception, d’exécution, d’intégration au reste du programme et, très souvent, une combinaison de ces facteurs. Les modifications ultérieures du code qui interagissent avec la dette technique, directement ou indirectement, peuvent révéler ou amplifier ces problèmes.

Pourquoi ? Pensez aux conditions dans lesquelles les programmeurs sont susceptibles d'ajouter de la dette technique. Généralement, un problème doit être résolu rapidement, et la rapidité compte plus que la bonne gestion du problème. Il peut s'agir d'une correction de bug urgente, d'une modification pour intégrer une mise à jour du système d'exploitation, de nouvelles fonctionnalités ajoutées dans un délai serré, d'un correctif de code provenant d'une autre source, 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é jusqu'à ce qu'il ne génère plus d'erreurs, mais il n'est pas conforme aux normes actuelles de conception ou de codage. C'est pourquoi il s'agit de dette technique, et pas seulement de nouveau code.

Cela signifie qu'il n'est probablement pas infaillible, et que les corrections de bugs et la gestion des erreurs seront probablement 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 modifications structurelles ultérieures, la probabilité d'échec risque d'augmenter. De même, les révisions ultérieures de votre logiciel peuvent solliciter au-delà de leurs limites les parties de votre code présentant une dette technique.

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, nombre d'entre eux le nécessitent. La révision du code est également le moment le plus opportun pour éliminer toute dette technique qu'il contient. Même lorsque la réponse à l'incident n'implique aucune modification du logiciel, elle peut révéler une dette jusque-là non identifiée, qui peut alors être planifiée pour révision. La gestion des incidents peut également servir de système d'alerte et de détection des problèmes sous-jacents dans la conception et le codage des logiciels. La répétition de problèmes impliquant le même bloc de code est un bon indicateur de problèmes au niveau du code lui-même.

Politique de la dette technique

Si la dette technique constitue actuellement (ou potentiellement) un problème majeur pour votre logiciel, vous pourriez adopter une politique globale et un cadre formel pour l'éliminer. Une politique de gestion de la 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 la gestion de la dette technique

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

• Cartographier les zones connues de dette technique dans votre code source. Une telle cartographie serait bien sûr susceptible d'évoluer, à mesure que de nouvelles dettes sont découvertes et que des dettes connues sont supprimées. Cela nécessiterait une définition interne de la dette technique, spécifiquement conçue pour permettre à toutes les parties concernées de la reconnaître et de la distinguer des variations acceptables de 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 la date et l'heure de découverte, une description succincte de la dette, la réponse apportée (correction, planification ultérieure, maintien en place), ainsi que les suivis. Les intervenants clés (chefs de projet, développeurs, etc.) devront comprendre leurs responsabilités concernant la journalisation manuelle. Une partie de la journalisation (par exemple, l'alerte initiale d'incident) peut probablement être automatisée.

• 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. Idéalement, bien sûr, tout problème de code existant, y compris la dette technique, devrait être traité immédiatement dans le cadre de la réponse à incident. Cependant, en pratique, de nombreuses situations sont impossibles. 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 consigner la dette technique, mais aussi pour planifier la révision du code concerné afin de s'en débarrasser.

• 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 et à maîtriser les normes à appliquer pour y remédier. Ces normes peuvent nécessiter d'inclure des lignes directrices pour la gestion des problèmes complexes de conception de code. La dette technique étant souvent le résultat d'une tentative de contournement des points faibles de la conception, toute solution concrète devra traiter ces problèmes de manière systématique et conforme aux normes de conception fondamentales de l'application.

Il existe plusieurs points sur lesquels un tel cadre gagnerait à être intégré à un système de gestion des incidents, notamment via l'API d'un système similaire. Par exemple, les rapports d'incidents pourraient être exportés vers l'application de cartographie de la dette, à la fois pour corréler les incidents avec les zones problématiques connues et pour cartographier la dette technique nouvellement identifiée. Les API des outils de gestion des incidents peuvent également servir à consigner les incidents impliquant une dette technique et à générer automatiquement des ordres de travail pour la résoudre. Ces outils pourraient également servir à alerter les développeurs chargés 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 son traitement. 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 afin d'éliminer complètement la dette technique. Elle garantit que celle-ci ne sera pas simplement repoussée à plus tard.