Tech Debt: Was ist das und wie geht man damit um?

Alle Teams müssen sich bei der Entwicklung eines Produkts mit Fristen, Budgets und anderen Beschränkungen auseinandersetzen.

All diese Parameter wirken sich auf die Entscheidungsfindung aus und führen zur Entstehung von technischen Schulden. Manchmal entstehen technische Schulden, weil eine Aktualisierung schnell durchgeführt werden muss. In anderen Fällen liegt es an mangelndem Verständnis oder mangelnder Erfahrung. Unabhängig von der Ursache müssen die Teams einen Weg finden, mit den technischen Schwierigkeiten umzugehen, damit sie sie in Zukunft nicht zu sehr ausbremsen. Durch das Verständnis und die Vorbereitung auf technische Schulden können Teams Updates schneller herausbringen, ihre Codebasis in einem Zustand halten, der die Arbeit erleichtert, und eine bessere Vorstellung von den Herausforderungen haben, denen sie in Zukunft gegenüberstehen werden.

Aber was ist Tech Debt?

Tech Debt ist die künftige Arbeit, die sich aus den Entscheidungen ergibt, die während der Entwicklung von Funktionen und Fehlerbehebungen getroffen werden. Es handelt sich um die Kompromisse, die wir eingehen, um ein Produkt zu schaffen. Manchmal kann die technische Schuld ziemlich groß sein; vielleicht muss ein System komplett neu architektiert werden, weil die aktuelle Implementierung eine sehr große Benutzerbasis nicht bewältigen kann. In anderen Fällen kann es sich um etwas Einfaches handeln, wie das Refactoring einer Klasse oder Funktion, wenn diese erweitert werden muss.

Defining, Identifying, and Measuring Technical Debt zeigt 13 Arten von technischen Schulden auf:

• Architektur-Schulden
• Schulden aufbauen
• Code Verschuldung
• Defekt-Schuld
• Design-Schulden
• Dokumentation Schulden
• Infrastruktur-Schulden
• Menschen Verschuldung
• Prozess-Schulden
• Anforderung Verschuldung
• Schuldendienst
• Testautomatisierung Schulden
• Test-Schulden

Eine ausführlichere Diskussion zu diesem Thema finden Sie in Towards an Ontology of Terms on Technical Debt, auf dem der obige Blogbeitrag basiert, der jedoch hinter einer Paywall liegt

Woher kommen die Tech-Schulden?

Die kurze Antwort ist, dass jede Produktentscheidung technische Schulden mit sich bringt. Bei dieser Entscheidung kann es um die Priorisierung einer neuen Funktion, die Aktualisierung des Designs, die Änderung des Backends usw. gehen. Das hört sich zwar schlimm an, ist aber nicht zwangsläufig eine schlechte Sache, da sich die Systeme mit den sich ändernden Anforderungen weiterentwickeln sollten. Um Geld zu sparen, kann ein System für einen kleinen Nutzerkreis entwickelt werden, wobei man weiß, dass es aktualisiert werden muss, wenn der Nutzerkreis wächst. Die durch diese Entscheidung verursachte Schuld wäre wahrscheinlich eine Architekturschuld. Wenn sich das System ändert und Sie wissen, dass Sie die Dokumentation aktualisieren müssen, dann haben Sie Dokumentationsschulden.

Wie können wir technische Schulden bewältigen?

Der erste Schritt besteht darin, dass Sie versuchen, die Folgen Ihrer Entscheidungen besser zu verstehen. Wenn Sie die technischen Schulden im Voraus kennen, können Sie sie einplanen. Je nach Ihrer Rolle sollten Sie sich nur um eine Teilmenge der 13 Arten von Tech Debt kümmern müssen. Sycorax, das Team, in dem ich mitarbeite, hatte die Idee, alle paar Monate nach wichtigen Meilensteinen einen "State of the Base" abzuhalten.

Zustand der Basis

Das Sycorax-Team stand kurz vor dem Beginn der Arbeit an einem neuen Projekt, und die Entwickler wollten besser vorbereitet sein. Als wir uns ansahen, was wir bereits gemacht hatten und wie wir die Lektionen, die wir gelernt hatten, anwenden konnten, beschlossen wir, einige unserer Beschwerden und Schmerzpunkte mit dem ersten Projekt aufzulisten. Wir haben dieses Konzept speziell für den Umgang mit Code-, Dokumentations- und Architekturschulden entwickelt, aber es lässt sich abwandeln und auf jede Art von technischen Schulden anwenden.

Wir erstellten ein Dokument, in dem wir einige der Probleme festhielten, und nahmen uns Zeit, um sie zu besprechen und zu überlegen, wie wir die Probleme verbessern oder in Zukunft vermeiden können. Schließlich einigten wir uns auf eine einfache Tabelle mit 5 Spalten:

Die Entwickler können dieses Dokument immer dann ergänzen, wenn sie etwas verbessern oder in Angriff nehmen wollen. Dies hilft uns, bei der Arbeit an den Funktionen auf dem richtigen Weg zu bleiben, während wir neue Tickets erstellen und darauf hinweisen, PRs überprüfen oder einfach nur an Teilen der Codebasis arbeiten, ohne dass technische Schulden durch die Maschen fallen. In der obigen Tabelle finden Sie zwei Beispiele, die wir jeweils als ziemlich einfach eingestuft haben, aber die Prioritäten waren unterschiedlich. Die Verbesserung unserer Protokolle kann uns helfen, einen Fehler für unsere Kunden zu diagnostizieren. Je eher wir ihn finden, desto eher können wir ihn lösen. Das zweite Beispiel dient lediglich dazu, das Schreiben von Tests zu vereinfachen. Es lohnt sich vielleicht nicht, unsere bestehenden Tests zu ändern, aber es ist etwas, das wir für zukünftige Tests im Hinterkopf behalten sollten.

Vorteile von State of the Base

• Arbeit, die für das Team wertvoll ist, bleibt auch dann verfügbar, wenn epikspezifische Tickets blockiert sein könnten.
• Einfache Übersicht über alle nicht funktionsbezogenen Verbesserungen, die an einer Stelle priorisiert sind
• Verhindert das Abdriften in technische Diskussionen und hilft dem Team, sich zu konzentrieren
  • Dieser Vorteil erstreckt sich auch auf PRs, wenn ein Problem auftaucht, das außerhalb des Geltungsbereichs liegt und für das entsprechende Folgemaßnahmen ergriffen werden sollten.
• Förderung der Eigenverantwortung, indem sichergestellt wird, dass Raum für die Überprüfung aller Verbesserungsideen geschaffen wird
• Fördert die konsequente Verbesserung der Wartbarkeit des Codes

Das hört sich toll an, aber wir haben keine Zeit, noch mehr Arbeit hinzuzufügen...

Technische Schulden verursachen mehr Arbeit, ob Sie das nun einplanen oder nicht. Das System kann den Datenverkehr nicht mehr bewältigen, die "schnelle Lösung" hatte Nebenwirkungen, die Sie nicht eingeplant hatten, mit denen Sie nun aber umgehen müssen, usw. Die technischen Schulden werden Sie einholen! Wenn Sie sie verstehen und einplanen, können Sie sich früher und möglicherweise schneller damit befassen, als wenn das Problem auftaucht und die Produktion unterbricht. Das bedeutet aber nicht, dass Sie ständig versuchen müssen, die technischen Schulden auf Kosten von Produktverbesserungen zu beseitigen. Wir schreiben alle unsere "State of the Base"-Tickets auf und halten sie im Backlog fest, damit die Entwickler sie abarbeiten können, wenn es die Zeit erlaubt. Durch das Hinzufügen der Spalten "Lift" und "Priorität" sind wir in der Lage, die Tickets für unseren PM besser zu formulieren. Wenn wir uns die Zeit nehmen, die technischen Schulden zu diskutieren und zu bestimmen, was behoben werden muss und was nicht, kann das Team erklären, warum die Änderungen erforderlich sind. Dies ist besonders wichtig, wenn wir Dinge vorschlagen, die die Benutzerinteraktion nicht verändern, wie die Aktualisierung des Datenbankschemas.

Schlussfolgerung

Unabhängig davon, ob Sie sich für "State of the Base" entscheiden oder Ihre eigenen Methoden entwickeln, sollte das Verständnis und die Planung für technische Schulden Teil Ihres Entscheidungsprozesses sein. Wenn Sie wissen, welche Probleme sich aus Ihren Entscheidungen ergeben werden, können Sie bessere Entscheidungen treffen und sind besser auf künftige Veränderungen vorbereitet.

Martin Mammel

Marty ist ein Software-Ingenieur bei FloQast. Wenn er nicht arbeitet, findet man ihn normalerweise auf einem Golfplatz, beim Spazierengehen mit seinem Hund oder beim Lesen eines Buches.