Was ist technischer Schulden (technical debt) in IT-Projekten?

Technische Schulden – das ist wie ein Kredit, den man aufnimmt, um die Entwicklung eines Softwareprodukts zu beschleunigen, aber dann beginnen die Zinsen in Form von erhöhtem Zeit- und Kostenaufwand für Wartung und Erweiterung der Funktionalität zu steigen. Dieser Begriff wurde von Howard Cunningham eingeführt, um Situationen zu beschreiben, in denen Entwickler während intensiver Arbeit die langfristige Sauberkeit des Codes zugunsten kurzfristiger Ziele ignorieren.

Sauberer Code – der Traum eines jeden Entwicklers, aber in der Praxis zwingen die Umstände oft zu Kompromissen. Der Druck seitens des Unternehmens, Fristen und ein begrenztes Budget können dazu führen, dass Funktionen veröffentlicht werden, bevor der Code zur Perfektion poliert ist. Temporäre Lösungen verwandeln sich allmählich in "schmutzigen Code (Code mit Geruch / code smell)", der die weitere Arbeit erschwert.

Ein Grund, warum Code von sauber zu schmutzig wird, ist das Fehlen von Dokumentation und automatisierten Tests. Dokumentation hilft neuen Teammitgliedern, das Projekt schneller zu verstehen, während automatisierte Tests den Code in einem stabilen Zustand halten und unerwartete Fehler bei Änderungen verhindern.

Die Entwicklung monolithischer Projekte, bei denen Änderungen an einem Ort unerwartete Auswirkungen auf andere Teile des Systems haben können, ist ebenfalls ein großes Hindernis für sauberen Code. Komponentenbeschränkungen und eine große Anzahl von Abhängigkeiten schaffen eine Situation, in der Refactoring nicht nur wünschenswert, sondern notwendig wird. Wenn Refactoring jedoch aufgeschoben wird, steigen die Kosten dafür im Laufe der Zeit exponentiell, da der abhängige Code weiterhin wächst.

Zu den weiteren Gründen für das Entstehen und die Zunahme technischer Schulden gehören das Fehlen klarer Interaktionen zwischen den Teammitgliedern, was zu einem "Salat" aus verschiedenen Codestilen führt, sowie das Fehlen einheitlicher Standards für das Schreiben von Code. Weiter unten finden Sie eine Liste häufiger Ursachen technischer Schulden.

Technische Schulden verlangsamen nicht nur die Entwicklung, sondern erhöhen auch das Risiko von Fehlern und verringern die Gesamtqualität des Softwareprodukts. Ähnlich wie bei finanziellen Schulden erfordert ihre Rückzahlung Zeit, Ressourcen und mutige Entscheidungen seitens des Managements für die langfristige Gesundheit des Projekts und des Teams.

Es gibt zeitliche Grenzen (Fristen) für die Implementierung von Funktionen eines Online-Shops. Das Entwicklerteam beschließt, schnell ein Bestellverwaltungssystem einzuführen. Zunächst entscheiden sie sich für eine einfache Datenbankstruktur, in der alle Bestelldaten, einschließlich Produktdetails, Kundeninformationen und Transaktionen, in einer Tabelle gespeichert werden. Diese Entscheidung ermöglicht es, Projekte (MVP) schnell zu starten, aber mit der zunehmenden Anzahl von Bestellungen und der Komplexität der Daten wird eine solche Struktur ineffizient.

Im Laufe der Zeit, wenn die Datenmengen zunehmen, werden die Datenbankabfragen langsam und weniger effizient, was zu längeren Bearbeitungszeiten für Bestellungen und einer verringerten Gesamtleistung der Website führt. Darüber hinaus ist es schwierig, Datenanalysen durchzuführen und die erforderlichen Berichte ohne Refactoring der Datenbankstruktur bereitzustellen.

Die Lösung dieses Problems erfordert erhebliche Anstrengungen zur Refaktorisierung der Datenbank, einschließlich der Neugestaltung von Tabellen, der Optimierung von Abfragen und möglicherweise der Implementierung neuer Caching-Technologien. Solches Refactoring wird Zeit und Ressourcen in Anspruch nehmen, die für die Entwicklung anderer Aspekte des Projekts hätten verwendet werden können, aber ohne diesen Schritt wird das zukünftige Wachstum und die Effizienz des Online-Shops eingeschränkt. Hier erkennen wir, was 'Schulden' sind. Das notwendige Refactoring kann in Zeit und Geld (Zahlung für die Arbeit des Teams) bewertet werden. Wenn wir diese Zeit / dieses Geld nicht von Anfang an investieren, haben wir uns selbst 'verschuldet', indem wir die Arbeit an einem komplexeren System auf später verschoben haben. Aber manchmal sind technische Schulden gerechtfertigt – wir erstellen ein MVP und starten das Projekt, um Einnahmen zu generieren. Erst danach können wir die erhaltenen Mittel in den Code refinanzieren.

Diese Liste ist nicht vollständig, aber konzeptionell denke ich, dass man das Wesen verstehen kann.

Druck vom Geschäft (Bedarf, mit dem Verkauf zu beginnen): Oft werden Projekte gestartet, bevor sie vollständig bereit sind. Die Entscheidung für einen schnellen Start kann Probleme schaffen, die Zeit für Refactoring und die Behebung möglicher Fehler erfordern. Es ist nicht auszuschließen, dass Fehler den ersten Eindruck potenzieller Kunden beeinflussen und sich auf den Verkauf auswirken.

Unverständnis der Auswirkungen technischer Schulden: Geschäftsinhaber sehen möglicherweise nicht die Folgen der Ignorierung technischer Schulden und betrachten sie als weniger wichtig als den unmittelbaren Markteintritt des Produkts. Manchmal ist es ziemlich schwierig, einer Person ohne Kenntnisse über IT-Prozesse zu erklären, warum Geld und Zeit für das Umschreiben / Schreiben von Code ausgegeben werden müssen. Das Bewusstsein kommt oft erst dann, wenn technische Schulden beginnen, das Geschäft zu beeinflussen.

Monolithische Architektur: Das Fehlen von Modularität bei der Systemgestaltung schränkt die Flexibilität ein und erfordert große Anstrengungen für Änderungen oder Verbesserungen, was die Anpassung an sich ändernde Geschäftsanforderungen verlangsamt.

Mangel an Tests: Das Fehlen umfassender Tests erhöht das Risiko von Fehlern, was zu schwerwiegenden Ausfällen in der Zukunft führen kann.

Mangel an Dokumentation: Wenn ein Projekt ohne angemessene Dokumentation entwickelt wird, benötigen neue Teammitglieder mehr Zeit, um das System zu verstehen, was ihre Produktivität verringert. Außerdem werden neue Entwickler alte mit Fragen ablenken. Möglicherweise gibt es während der Code-Überprüfung mehr Anfragen zur Korrektur des Codes (von Entwicklern, die die Nuancen des Codes, der Architektur, der Geschäftsprozesse usw. kennen).

Schlechte Interaktion / Kommunikation: Wenn Wissen und Erfahrung nicht innerhalb der Organisation verbreitet werden, sinkt die Effizienz der Arbeit.

Parallele Entwicklung in mehreren Branches: Paralleles Programmieren in mehreren Branches schafft Schwierigkeiten beim Zusammenführen von Code und akkumuliert technische Schulden, die vor dem Start abgebaut werden müssen.

Aufschub des Refactorings: Zögern bei der Optimierung des Codes schafft eine Situation, in der der Code immer schwieriger zu warten und zu erweitern wird.

Nichtbeachtung von Standards: Das Ignorieren festgelegter Standards und Konventionen kann die zukünftige Integration und Wartung des Projekts erschweren.

Mangel an Kompetenz: Wenn Entwickler nicht über ausreichende Fähigkeiten verfügen, um sauberen, effektiven Code zu schreiben, kann dies zur Schaffung eines problematischen Produkts führen.

Entwicklung durch Auftragnehmer: Softwareprodukte, die von Auftragnehmern entwickelt und dann in das Projekt integriert werden, erfordern häufig zusätzliche Ausgaben für ihre Anpassung und Optimierung.

Schlechte Führung: Ineffektive Führung kann technische Schulden durch unzureichend durchdachte Prozesse erhöhen.

Änderungen der Spezifikation in letzter Minute: Diese Änderungen können eine Kette notwendiger Anpassungen im Projekt auslösen, ohne dass genügend Zeit für deren Implementierung (Optimierung, Tests usw.) bleibt.

Scope Creep: Unkontrollierte Reduzierung oder Verschiebung des Arbeitsumfangs kann zusätzlichen Druck erzeugen und technische Schulden durch ungeplante Änderungen im Projekt erhöhen.