Was sind Tech-Schulden?

Technische Schulden sind bekannte technische Implementierungspunkte, von denen man sich möglicherweise bewusst entschieden hat, sie jetzt nicht umzusetzen. Tech-Schulden sind üblich, müssen aber mit Bedacht durchdacht werden. Wir werden einige Richtlinien dazu vorstellen, wann und wie sie zu bewerten sind.

Im Idealfall sollte jeder Code bei seiner ersten Implementierung alle bekannten Fälle behandeln. Allerdings kann es Blockaden geben:

1. In einigen hoffentlich ungewöhnlichen Fällen ist die Produktfunktionalität oder die technische Logik möglicherweise nicht klar. Dabei kann es sich auch um unklare Umfangs- oder Verkehrsanforderungen handeln, wodurch das Risiko einer unzureichenden oder übermäßigen Vorbereitung auf Verkehr und Umfang besteht.
2. Auch wenn die Implementierung für ungewöhnliche Anwendungsfälle klar ist, kann die Implementierung komplex oder zeitaufwändig sein.

Im Idealfall möchten wir alle die technischen Schulden minimieren, aber es gibt Zeiten, in denen es sinnvoll ist, sie einzugehen.

Die Notwendigkeit, voranzukommen

Auch wenn es sich negativ auswirken kann, wenn nicht alle Details vorliegen oder die vollständige Implementierung nicht vorliegt, muss man oft aus einer Kombination der folgenden Gründe weitermachen:

1. Oftmals muss man etwas erstellen oder implementieren, um weitere Fragen zu beantworten und dabei das teilweise Feedback von Anwendern oder Kunden zu nutzen. Dithering kann zu kostspieligen Verzögerungen führen, und es ist ratsam, das Risiko einer nicht perfekten Implementierung statt gar keiner einzugehen.
2. Der spezifische Mangel an Klarheit kann im Gesamtschema der zu erstellenden Funktionalität relativ unbedeutend sein, kann leicht hinzugefügt oder korrigiert werden, und die Nichtimplementierung der Funktionalität kann teurer sein.

Qualitäten

Wenn wir technische Schulden aufnehmen, haben wir uns bewusst dafür entschieden, eine vielleicht korrektere Implementierung gegen eine teilweise Implementierung einzutauschen. Eine gute technische Schuld:

1. Wenn die technischen Schulden behoben werden, führt dies zu einer geringeren Code-Abwanderung des Codes der aktuell gewählten Implementierung und
2. Führt zu einem ordnungsgemäßen Ausfall eines ungewöhnlichen Teils der Funktionalität. Im Gegensatz dazu handelt es sich bei einer Behebung um eine schrittweise Verbesserung der Funktion.

Man darf nur die guten technischen Schulden aufnehmen, die die oben genannten Eigenschaften erfüllen. Die folgenden Fragen helfen uns bei der Bewertung.

Kosten

Einige Fragen, die Sie stellen sollten, wenn Sie die Kosten für die Übernahme der technischen Schulden oder eines verpassten Falls bewerten:

1. Wo liegt die fehlende Funktionalität – z. B. bei der Datenvisualisierung/-präsentation oder der Datengenerierung? Konkret: Führt die fehlende Funktionalität zu dauerhaft falschen Daten?
2. Was ist der Nachteil der Benutzererfahrung? Handelt es sich um einen häufigen Anwendungsfall, über den Benutzer wahrscheinlich stolpern und unzufrieden sind, oder um einen ungewöhnlichen Fall am Rande unseres Kernwertversprechens?
3. Sind wir uns über die Details des fehlenden oder übersprungenen Funktionsdesigns und der Implementierung sicher? Oder möchten wir lieber Feedback zur Teilumsetzung haben, um diese zu definieren?

Wir übernehmen technische Schulden für bestimmte Vorteile:

1. Schnellere Veröffentlichung, was möglicherweise zu höheren Umsätzen oder mehr Kundenzufriedenheit führt.
2. Es besteht die Möglichkeit, Akzeptanzdaten oder Feedback zu erhalten, was möglicherweise zu einem besseren Design der fehlenden Funktionalität führt. Für einige unklare Funktionen kann dies erforderlich sein.
3. Die Opportunitätskosten des kurzfristig eingesparten Engineering-Aufwands.

Durch die Befolgung grundlegender Grundprinzipien des robusten Designs wird der Nacharbeitsaufwand minimiert, der mit der Bewältigung der technischen Schulden einhergeht.

Modularität

Stellen Sie sicher, dass die Dienste und Objekte gut durchdacht sind und über klar definierte Schnittstellen verfügen. Durch die Modularität können Änderungen lokalisiert werden, ohne dass der Aufwand für die Codeüberarbeitung minimiert wird.

Versuchen Sie, über das Unmittelbare hinauszudenken, z

1. Wenn wir derzeit eine Implementierung der Funktionalität haben, können wir die Implementierung später möglicherweise als Unterklasse einer Schnittstelle festlegen. Dies erleichtert das spätere Hinzufügen weiterer Implementierungen.
2. Wenn eine Entität derzeit über einen möglichen Wert für das Feld verfügt, später jedoch möglicherweise über mehr verfügt, machen Sie daraus eine Aufzählung.

Sauberes Schema

Ein gutes Datenbankschema und ORM-Modell, das den realen Anwendungsfall genau nachbildet, ist in der Regel robust gegenüber weiteren Änderungen.

Gute Codierungspraktiken

1. Halten Sie die Werte, die möglicherweise angepasst werden, trocken und nicht tief im Code. Dabei kann es sich entweder um Laufzeit-Eingabekonfigurationsvariablen oder um Codekonstanten handeln. Dies muss eine bewusste Entscheidung sein.
2. Einige Funktionen erfordern die Fähigkeit, entweder schnell zu iterieren oder je nach Kunde angepasst zu werden. Verwenden Sie Low-/No-Code-Tools, sie lassen sich leicht iterieren – sogar einigermaßen von einem Nicht-Ingenieur. Und es gibt weniger Code und damit weniger Abwanderung.
3. Es gelten die oben genannten allgemeinen Codierungs- und Designpraktiken – z. B. halten Sie den Code trocken (es ist einfach, Code an einer Stelle zu ändern), halten Sie ihn einfach (dadurch ist die Änderung leichter zu verstehen) usw.
4. Einige Änderungen werden additiv sein – im wahrsten Sinne des Wortes auf dem Status Quo aufbauen – z. B. das Hinzufügen von Replikatsätzen zu einem vorhandenen Einzelknoten-Mongo-Datenbankserver oder das Sharding zu einem Mongo-Datenbankserver. Sollte die Implementierung teuer sein, kann die Notwendigkeit solcher Verbesserungen ohne zusätzlichen Aufwand auf einen späteren Zeitpunkt verschoben werden, bis sie benötigt werden.

Die Nichtbearbeitung aller Fälle ist kein ausreichender Grund, den Code einzuchecken. Stattdessen finden Sie im Folgenden eine Möglichkeit, wie Sie vorankommen können:

1. Übertragen Sie in Ihrer Branche weiterhin Code mit zahlreichen TODOs-Kommentaren zu den ausstehenden Funktionen oder Klärungspunkten.
2. Lösen Sie im Idealfall alle TODOs auf, bevor Sie die Pull-Anfrage stellen.
3. Jedes ungelöste Problem wird zu einer technischen Schuld – stellen Sie sicher, dass der Code-Reviewer und der relevante technische Manager/Leiter im Kommentar mit „/Information“, der von Jira erstellten technischen Schuld und der Jira-ID gekennzeichnet sind. Die PR-Überprüfung sollte hoffentlich erneut bestätigen, dass die Tech-Schulden akzeptabel sind.
4. Stellen Sie sicher, dass der Code selbst die nicht behandelten Fälle ordnungsgemäß behandelt – z. B. erhält das Front-End eine entsprechende API-Antwort, um den Fehler einer noch nicht behandelten API-Eingabe anzuzeigen, anstatt das Backend zum Absturz zu bringen.
5. Behalten Sie einen Zeitplan für die Tech-Schulden von Jira im Hinterkopf, indem Sie ihn möglicherweise im nächsten Sprint beibehalten, damit er im Sprint-Planungsaufruf zur ersten Überprüfung auftaucht.