Generell lohnt es sich, über Bezeichnungen wie „Vorfallmanagement“ hinauszublicken (was normalerweise viel mehr bedeutet als das Empfangen und Reagieren auf Warnmeldungen). Betrachten Sie beispielsweise die Beziehung zwischen Vorfällen und technischer Schuld. Es ist eine Beziehung, über die die meisten Softwareexperten wahrscheinlich noch nicht einmal nachgedacht haben, aber sie existiert und ist mehr als nur eine 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 des Problems. Es kann sich um eine dringende Fehlerbehebung handeln, eine Änderung zur Anpassung an ein Betriebssystem-Update, neue Funktionen, die unter Zeitdruck hinzugefügt werden, Code aus einer anderen Quelle, der eingepatcht wird, oder einfach um eine schnelle Problemumgehung, um vorherige technische Schulden auszugleichen. Wenn der Code hinzugefügt wird, wird er bereinigt und soweit debuggt, dass er keine Fehler mehr verursacht, aber er entspricht nicht mehr den modernen Design- oder Codierungsstandards. Deshalb handelt es sich um technische Schulden und nicht nur um neuen Code.

Das bedeutet, dass es wahrscheinlich nicht narrensicher ist und dass die Fehlerbehebungen und die Fehlerbehandlung 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 zusätzlichem Verkehr oder späteren Strukturänderungen steigt die Wahrscheinlichkeit eines Ausfalls wahrscheinlich. Auf die gleiche Weise 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 Vorfallmanagement ins Spiel? Obwohl nicht alle Vorfälle eine Analyse und Überarbeitung des Quellcodes erfordern, ist dies bei vielen der Fall. Der Zeitpunkt, an dem der Code überarbeitet wird, ist auch der offensichtlichste Zeitpunkt, um darin enthaltene technische Schulden zu beseitigen. Selbst wenn die Reaktion auf den Vorfall selbst keine Änderungen an der Software erfordert, kann sie zur Entdeckung bisher unerkannter Schulden führen, die dann zur Überarbeitung eingeplant werden können. Das Vorfallmanagement kann auch als Warn- und Erkennungssystem für zugrunde liegende Probleme im Softwaredesign und in der Codierung dienen. Wiederholte Probleme mit demselben Codeblock sind ein guter Hinweis auf Probleme mit dem Code selbst.

Richtlinie zu technischer Schuld

Wenn technische Schulden derzeit (oder möglicherweise) ein erhebliches Problem Ihrer Software darstellen, sollten Sie eine allgemeine Richtlinie und einen formellen Rahmen für die Beseitigung technischer Schulden einführen. Eine Richtlinie für technische Schulden könnte die folgenden allgemeinen Bereiche abdecken:

• Technische Schulden identifizieren und abbilden
• 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 diese umfassen:

• Aufzeigen bekannter Bereiche technischer Schulden in Ihrem Quellcode. Eine solche Karte würde sich natürlich ändern, sowohl wenn neue Schulden entdeckt werden als auch wenn 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 im Zusammenhang mit neuen und bekannten technischen Schulden. Das Protokoll selbst sollte Angaben wie Uhrzeit/Datum der Entdeckung, eine grundlegende Beschreibung der Schuld und die Reaktion (Behebung, späterer Termin, Belassen) sowie Folgemaßnahmen enthalten. Wichtige Parteien (Projektmanager, Entwickler usw.) müssen sich ihrer Verantwortung hinsichtlich der manuellen Protokollierung bewusst sein. Einige Protokollierungsvorgänge (z. B. die erste Meldung des Vorfalls) können wahrscheinlich automatisiert werden.

• Richtlinien, die festlegen, wann die Schulden als Teil der Reaktion auf den Vorfall beglichen werden sollen, und wann die Schulden gemeldet und zukünftige Begleichungen geplant werden sollen. Im Idealfall würden natürlich alle bestehenden Codeprobleme, einschließlich technischer Schulden, im Rahmen der Vorfallreaktion sofort behoben. In der Praxis gibt es jedoch viele Situationen, in denen dies einfach nicht möglich ist. 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, um nicht nur technische Schulden zu protokollieren, sondern auch eine Überarbeitung des betroffenen Codes zu planen, um diese Schulden zu beseitigen.

• Eine Reihe formaler Codestandards mit besonderem Bezug auf technische Schulden . Dazu gehört, dass man lernt, wie man technische Schulden erkennt, und dass man lernt, welche Standards man anwenden muss, um sie zu beheben. Standards müssen möglicherweise Richtlinien für den Umgang mit schwierigen Problemen beim Codedesign enthalten. Da technische Schulden oft das Ergebnis eines Versuchs sind, Design-Problemstellen zu umgehen, muss jede echte Lösung diese Probleme systematisch und im Einklang mit den grundlegenden Designstandards der Anwendung angehen.

Es gibt mehrere Punkte, an denen ein solches Framework von der Anbindung an ein Vorfallmanagementsystem profitieren würde, insbesondere über die API eines ähnlichen Systems. Beispielsweise könnten Vorfallberichte in die Anwendung exportiert werden, die zur Schuldenabbildung verwendet wird, sowohl zum Zweck der Korrelation von Vorfällen mit bekannten Problembereichen als auch zur Abbildung neu identifizierter technischer Schulden. APIs von Vorfallmanagementtools können auch verwendet werden, um Vorfälle mit technischen Schulden zu protokollieren und automatisch Arbeitsaufträge zur Behebung dieser Schulden zu generieren. Diese Tools könnten auch verwendet werden, um Entwickler zu benachrichtigen, die für die Handhabung technischer Schulden in bestimmten Bereichen des Codes verantwortlich sind.

Ein solches Framework ermöglicht es, technische Schulden schrittweise als Teil eines Systems für Vorfallmanagement und -reaktion zu beseitigen, und bietet eine automatisierte Methode, um sicherzustellen, dass technische Schulden abgearbeitet werden. Das Vorfallmanagement ist ein zentraler Aspekt des Frameworks und bietet Tools zum Erkennen von schuldbezogenen Problemen, zum Benachrichtigen der Verantwortlichen und zum Planen von Coderevisionen, um technische Schulden vollständig zu beseitigen. Es stellt sicher, dass die Probleme nicht einfach auf die lange Bank geschoben werden.