Es lohnt sich, über Bezeichnungen wie „Incident Management“ hinauszublicken (was in der Regel viel mehr bedeutet als das Empfangen und Reagieren auf Warnmeldungen). Betrachten Sie beispielsweise den Zusammenhang zwischen Vorfällen und technischer Schuld. Es ist ein Zusammenhang, über den die meisten Softwareexperten wahrscheinlich noch nicht einmal nachgedacht haben, aber er existiert und ist mehr als nur flüchtige Bekanntschaft.

Obwohl neuer oder kürzlich überarbeiteter Code für die Mehrzahl der Softwarefehler verantwortlich ist, führt die Rückverfolgung der durch Codeänderungen verursachten Probleme sehr häufig zu alten Code-Patches, die technische Schulden enthalten.

Das sollte eigentlich nicht überraschen. Technische Schulden sind per Definition Code, der eingebaute Probleme enthält – im Design, in der Ausführung, in der Integration mit dem Rest des Programms und sehr oft in einer Kombination dieser Faktoren. Spätere Änderungen am Code, die direkt oder indirekt mit technischen Schulden interagieren, können diese Probleme offenlegen oder verstärken.

Warum? Bedenken Sie die Bedingungen, unter denen Programmierer wahrscheinlich technische Schulden machen. Normalerweise gibt es ein Problem, das schnell behoben werden muss, und Geschwindigkeit ist wichtiger als die richtige Lösung. Es kann sich um eine dringende Fehlerbehebung handeln, eine Änderung anlässlich eines Betriebssystem-Updates, neue Funktionen, die unter Zeitdruck hinzugefügt werden, Code aus einer anderen Quelle, der eingepatcht wird, oder einfach nur um eine schnelle Problemumgehung, um alte technische Schulden auszugleichen. Wenn der Code hinzugefügt wird, wird er bereinigt und so weit debuggt, dass er keine Fehler mehr verursacht, aber er entspricht nicht mehr den modernen Design- oder Programmierstandards. Deshalb handelt es sich um technische Schulden und nicht einfach nur um neuen Code.

Das bedeutet, dass es wahrscheinlich nicht absolut sicher ist und Fehlerbehebungen und Fehlerbehandlungen wahrscheinlich improvisiert und zusammengeflickt werden. Es ist, als würde man eine Brücke mit einem schlecht konstruierten Fachwerk oder schwachen Trägern bauen. Die Problemstellen mögen zunächst in Ordnung sein, aber mit zunehmendem Verkehr oder späteren strukturellen Änderungen steigt die Ausfallwahrscheinlichkeit. Ebenso können spätere Überarbeitungen Ihrer Software die Teile Ihres Codes, die technische Schulden enthalten, über ihre Grenzen hinaus beanspruchen.

Vorfallmanagement und technische Schulden

Wo kommt das Incident Management ins Spiel? Zwar erfordern nicht alle Incidents eine Analyse und Überarbeitung des Quellcodes, aber viele. Die Überarbeitung des Codes ist auch der beste Zeitpunkt, um darin enthaltene technische Mängel zu beseitigen. Selbst wenn die Reaktion auf den Incident selbst keine Änderungen an der Software erfordert, können bisher unerkannte Mängel aufgedeckt und zur Überarbeitung eingeplant werden. Das Incident Management kann auch als Warn- und Erkennungssystem für zugrunde liegende Probleme bei Softwaredesign und -programmierung dienen. Wiederholte Probleme mit demselben Codeblock sind ein guter Hinweis auf Probleme mit dem Code selbst.

Richtlinie zur technischen Schuld

Wenn technische Schulden aktuell (oder potenziell) ein erhebliches Problem Ihrer Software darstellen, empfiehlt es sich, eine allgemeine Richtlinie und einen formalen Rahmen zur Beseitigung technischer Schulden einzuführen. Eine Richtlinie zur technischen Schuldenbeseitigung könnte die folgenden allgemeinen Bereiche abdecken:

• Identifizierung und Zuordnung technischer Schulden
• Richtlinien zur Identifizierung und Behebung technischer Schulden
• Kodierungsstandards

Ein Rahmen für den Umgang mit technischen Schulden

Der Rahmen für die Umsetzung einer solchen Politik könnte Komponenten wie die folgenden umfassen:

• Aufzeigen bekannter Bereiche technischer Schulden in Ihrem Quellcode. Eine solche Zuordnung würde sich natürlich ändern, sowohl wenn neue Schulden entdeckt als auch bekannte Schulden beseitigt werden. Dies würde eine interne Definition technischer Schulden erfordern, die speziell darauf ausgelegt ist, dass alle Beteiligten sie erkennen und von akzeptablen Variationen im Codierstil unterscheiden können.

• Verfahren zum Protokollieren von Vorfällen mit neuen und bekannten technischen Schulden. Das Protokoll selbst sollte unter anderem Datum und Uhrzeit der Entdeckung, eine grundlegende Beschreibung des Fehlers und die Reaktion (Behebung, spätere Planung, Belassen) sowie Folgemaßnahmen enthalten. Wichtige Beteiligte (Projektmanager, Entwickler usw.) müssen ihre Verantwortung für die manuelle Protokollierung kennen. Ein Teil der Protokollierung (z. B. die erste Meldung) lässt sich wahrscheinlich automatisieren.

• Richtlinien, die festlegen, wann die Schulden im Rahmen der Reaktion auf den Vorfall beglichen werden müssen und wann die Schulden gemeldet und zukünftige Behebungsmaßnahmen geplant werden müssen. Idealerweise werden alle bestehenden Codeprobleme, einschließlich technischer Schulden, im Rahmen der Vorfallsreaktion sofort behoben. In der Praxis ist dies jedoch oft nicht möglich. Die Dringlichkeit des Vorfalls lässt möglicherweise keine Zeit, sich um andere Dinge als das unmittelbare Problem zu kümmern. Es ist wichtig, ein formelles System zu haben, das nicht nur die technischen Schulden protokolliert, sondern auch die Überarbeitung des betroffenen Codes plant, um diese Schulden gezielt zu beseitigen.

• Eine Reihe formaler Codestandards mit besonderem Bezug auf technische Schulden . Dazu gehört das Erlernen des Erkennens technischer Schulden sowie der anzuwendenden Standards zu deren Behebung. Standards müssen möglicherweise Richtlinien für den Umgang mit schwierigen Problemen beim Code-Design enthalten. Da technische Schulden oft das Ergebnis des Versuchs sind, Design-Probleme zu umgehen, muss jede echte Lösung diese Probleme systematisch und im Einklang mit den grundlegenden Designstandards der Anwendung angehen.

Die Anbindung eines solchen Frameworks an ein Incident-Management-System, insbesondere über dessen API, bietet zahlreiche Vorteile. So könnten beispielsweise Incident-Berichte in die Anwendung zur Schuldenabbildung exportiert werden, um Incidents mit bekannten Problembereichen zu korrelieren und neu identifizierte technische Schulden abzubilden. Die APIs von Incident-Management-Tools können zudem genutzt werden, um Incidents mit technischen Schulden zu protokollieren und automatisch Arbeitsaufträge zur Behebung dieser Schulden zu generieren. Diese Tools könnten auch genutzt werden, um Entwickler zu benachrichtigen, die für die Bearbeitung technischer Schulden in bestimmten Codebereichen verantwortlich sind.

Ein solches Framework ermöglicht die schrittweise Beseitigung technischer Schulden im Rahmen eines Systems für Vorfallmanagement und -reaktion und bietet eine automatisierte Methode zur Sicherstellung der technischen Schuldenbewältigung. Das Vorfallmanagement ist ein zentraler Aspekt des Frameworks und bietet Tools zur Erkennung schuldenbezogener Probleme, zur Benachrichtigung der Verantwortlichen und zur Planung von Code-Revisionen zur vollständigen Beseitigung technischer Schulden. Es stellt sicher, dass die technische Schuld nicht einfach auf die lange Bank geschoben wird.