Berechnung der technischen Schulden: geschwindigkeitsbasiert vs. Problembasiert vs. Qualitätsbasierte Messungen erklärt

Die Zinssätze sind um 157 % gestiegen!

Nein, ich spreche nicht von der jüngsten Entscheidung der Fed, sondern von der Verlangsamung, mit der Fictional Inc. nach der Veröffentlichung der Version 3.0 ihrer Plattform konfrontiert war.

Zum Glück für sie war die Produktveröffentlichung unglaublich erfolgreich und sie sehen, dass das Umsatzwachstum schnell zunimmt, aber sie müssen jetzt darüber nachdenken, wie sie mit ihren technischen Schulden umgehen, die sie im Rahmen der Veröffentlichung eingeführt haben.

Die neuen technischen Schulden, die im Rahmen einer neuen Version eingeführt wurden, können als eine Erhöhung des Zinssatzes und eine zunehmende Verlangsamung des Teams in der Zukunft angesehen werden.

(Ich gehe davon aus, dass Sie mit dem Konzept der technischen Schulden hier einigermaßen vertraut sind, aber wenn Sie eine Auffrischung benötigen, um sich auf den neuesten Stand zu bringen, finden Sie hier eine kurze Zusammenfassung Grundierung )

Ok, Sie werden wahrscheinlich nicht hören, dass ein technischer Manager so über seine technischen Schulden spricht.

Aber warum nicht?

In der Lage sein, die anhaltenden Auswirkungen Ihrer Maßnahmen zu messen und zu quantifizieren Tech-Schulden sind von entscheidender Bedeutung wenn Sie einen umsetzbaren Plan zur Lösung des Problems erstellen möchten.

Wenn wir an technische Schulden denken, ist der Zins die Zeit, die bei der aktuellen und zukünftigen Entwicklung Ihrer bestehenden technischen Schulden verloren geht.

Dies bedeutet, dass dies der entscheidende Teil der Schulden ist, den es zu berücksichtigen gilt, wenn wir über zukünftige Entscheidungen zur Rückzahlung des Kapitals nachdenken (die Kosten für das Umschreiben, Refactoring oder die Korrektur des für die Schulden verantwortlichen Codes) – da wir ihn immer nur berücksichtigen, wenn die Zinsen anfallen ist hoch genug.

Was ist ein gesundes Maß an technischer Verschuldung?

Technische Schulden verlangsamen eindeutig neue Entwicklungen – aber das allein bedeutet nicht, dass wir überall technische Schulden beheben sollten. Das erneute Schreiben oder Refactoring von bestehendem Code kann sehr kostspielig sein. Daher möchten wir unsere technischen Schulden nur dann zurückzahlen, wenn unsere Zinsen (der Betrag, der uns bei der Weiterentwicklung verlangsamt) unseren Kapitalbetrag übersteigen.

Ein offensichtliches Problem taucht sofort auf: Der Kapitalbetrag ist eine feste Zeiteinheit (zu reparierende/umzuschreibende Stunden), aber die Zinsen sind die Rate der pro Zeit verlorenen Stunden. Um dies zu berücksichtigen, müssen wir die Idee eines Auswirkungsintervalls einführen – den Zeitraum, in dem wir uns darum kümmern, ob die zukünftigen Verlangsamungen aufgrund technischer Schulden die Kosten für die Neufassung übersteigen. Das für Sie relevante Auswirkungsintervall hängt stark von Ihrem Unternehmen, Ihrem typischen Planungsprozess und dessen Phase oder dem Lebenszyklus Ihrer Codebasis ab – ich persönlich gehe jedoch normalerweise von einem Auswirkungsintervall von drei Monaten aus. In unserem frühen Stadium als Unternehmen ist die Betrachtung von Zeiträumen über ein Jahr oder mehr zu weit gefasst, aber alles, was kürzer als zwei bis drei Monate ist, wird die Auswirkungen der technischen Verschuldung stark unterschätzen, wie wir später sehen werden.

Das bedeutet, dass es sich nicht lohnt, unsere technische Verschuldung in Angriff zu nehmen, wenn:

Wenn wir zum Beispiel ein kleines Projekt hätten, von dem wir wüssten, dass es technische Schulden hat, die uns um 2 Stunden pro Woche verlangsamt haben, würden wir 4 Tage brauchen, um diese Schulden zu beseitigen, und uns um ein 3-monatiges Auswirkungsintervall kümmern, dann würden wir das nicht tun Nehmen Sie sich noch die Zeit, diese Schulden zu begleichen.

Nun, das entspricht nicht wirklich der Höhe einer gesunden technischen Verschuldung – denn ich denke, wir sind uns alle einig, dass es nicht gesund ist, mit großen Verlangsamungen im Team konfrontiert zu sein. Stattdessen haben wir jetzt eine schnelle Möglichkeit zu bestimmen, wann wir uns auf das Umschreiben und Refactoring konzentrieren sollten oder nicht. Was eine gesunde Verschuldung tatsächlich ist, schauen wir uns etwas später in diesem Artikel an.

Wie messen wir technische Schulden?

Um den Zinssatz für unsere Tech-Schulden zu bestimmen, müssen wir herausfinden, wie sehr wir durch die verschiedenen Entscheidungen, die wir getroffen haben, ausgebremst werden. Leider gibt es keine offensichtliche oder triviale Möglichkeit, zu verfolgen, wie sehr Ihre Entwicklung verlangsamt wird – aber Sie können drei verschiedene Ansätze verfolgen, um gute Näherungen zu erhalten.

Geschwindigkeitsbasierte Messung

Der direkteste Weg, Verlangsamungen mit verschiedenen Abschnitten unserer Codebasis zu verknüpfen, besteht darin, zu untersuchen, wie sich die Geschwindigkeit im Laufe der Zeit in verschiedenen Abschnitten Ihres Projekts ändert. Wenn Sie sich verschiedene Bereiche der Codebasis ansehen, können Sie beginnen, Variationen in den verschiedenen Abschnitten zu identifizieren (z. B. dauert jede Entwicklung, die diesen Analyseabschnitt berührt, dreimal so lange wie alles andere). Die Betrachtung der Veränderung eines Gebiets im Laufe der Zeit kann Ihnen auch einen Hinweis darauf geben, wie sich neue Entwicklungen auf das Tempo der zukünftigen Entwicklung ausgewirkt haben, und gibt Aufschluss darüber, wie groß das Interesse ist, mit dem sich Ihr Team befasst.

Beispiel: Wenn wir ein relativ einfaches Projekt mit vier verschiedenen Bereichen haben, an denen wir arbeiten, können wir uns ansehen, wie sich die Geschwindigkeit im Laufe der Zeit ändert (hier verfolgen wir die Geschwindigkeit in Story Points/Entwicklermonat).

Geschwindigkeitsbasierte Messung der Auswirkungen technischer Schulden

Daraus können wir ersehen, dass die Bearbeitung von D bei ähnlich komplexen Aufgaben immer etwa dreimal so lange gedauert hat wie in allen anderen Bereichen. Dies bedeutet, dass er dreimal so interessant ist wie alle anderen Abschnitte der Codebasis. Früher war B relativ gleichwertig mit A und C, aber ab Monat 4 stieg es plötzlich an und dauerte doppelt so lange. Dies deutet darauf hin, dass wir hier Schulden eingeführt haben, die unseren Zinssatz gegenüber dem vorherigen für B verdoppelt haben.

Es muss darauf hingewiesen werden, dass wir hier nicht über den Zinssatz für die gesamte Codebasis sprechen, sondern über den Zinssatz für einzelne Komponenten/Bereiche – denn die Verlangsamungen, die durch die Anhäufung technischer Schulden entstehen, sind in der Regel kein so großes Problem wirken sich auf alles aus, was wir tun, sondern sind auf einen Teil der Codebasis beschränkt.

Bei der geschwindigkeitsbasierten Messung sind einige wichtige Vorbehalte zu beachten.

• Die Geschwindigkeit kann volatil sein und von Faktoren abhängen, die unabhängig von technischen Schulden sind, wie z. B. neuen (oder bestehenden) Fehlern, falsch abgestimmten Schätzungen, technischen Hürden oder externen Projektverzögerungen.

• Schätzungen weisen ein gewisses Maß an inhärenter Unsicherheit auf und können zunächst einmal eine ungenaue Messung sein.

• Das Sammeln und Analysieren dieser Daten kann schwierig und zeitaufwändig sein.

  
  

Ein schneller Anhaltspunkt für geschwindigkeitsbasierte Messungen besteht darin, Ihr Entwicklungsteam zu bitten, relativ zu schätzen, wie lange es dauert, ein Projekt/eine Aufgabe in jedem wichtigen Bereich Ihrer Codebasis abzuschließen. Vereinbaren Sie eine festgelegte Basislinie für einen gut verstandenen/häufig genutzten Bereich und lassen Sie dann alle die Bereiche der anderen als Prozentsatz oder Vielfaches dieser Basislinie schätzen. Obwohl es nicht ganz so streng ist wie ein auf Vollgeschwindigkeit basierender Messansatz, kann es auf der Grundlage der Einsichten und Intuition Ihres Teams einen schnellen Überblick über Ihre relativen Tech-Schuldenzinsen geben.

Problembasierte Messung

Ein anderer Ansatz besteht darin, bestimmte Fälle technischer Schulden in Ihrem Projekt zu identifizieren und abzuschätzen, wie sehr sie Sie jeweils verlangsamen. Ein Teil davon kann durch den Einsatz automatisierter Tools, wie z. B. statischer Analysetools, erreicht werden, um häufige Probleme im Zusammenhang mit der Codequalität zu finden, die Auswirkungen auf die Lesbarkeit, Erweiterbarkeit oder Wartbarkeit eines Projekts haben können. Für jede Art von Problem können Sie basierend auf der Erfahrung Ihres Teams im Umgang mit dieser Art von Problemen einen Zinsaufwand (z. B. 5 Min./Woche oder 1 %) zuweisen.

Dadurch wird jedoch nur ein Teil der technischen Schulden erfasst, die Probleme verursachen – andere sind subtiler oder eher auf Ihre Codebasis zugeschnitten und werden nur beobachtet, während Ihr Team aktiv an diesem Bereich des Codes arbeitet. In diesem Fall möchten Sie das spezifische Problem (im Zusammenhang mit einem Bereich Ihrer Codebasis) zusammen mit den geschätzten Auswirkungen, die es auf die Verlangsamung der Entwicklung hat, aufzeichnen. Um diese Probleme zu verfolgen, empfehlen wir die Verwendung einer Art Issue-Tracker – entweder in einem Issue-Backlog in GitHub, Jira usw. oder mithilfe eines speziell entwickelten technischen Schulden-Issue-Trackers wie z Schrittlänge .

Einige der Nachteile dieses Ansatzes sind:

• Die an bestimmte Probleme gebundenen Zeitschätzungen können ungenau sein
• Manche Probleme können leicht über einen längeren Zeitraum unentdeckt bleiben

Qualitätsbasierte Messung

Es gibt eine Vielzahl von Kennzahlen zur Codequalität, die Sie verwenden können, um sich einen Gesamtüberblick über den Status Ihrer Codebasis zu verschaffen und so wiederum eine Schätzung darüber zu erhalten, wie viel technische Verschuldung Sie derzeit haben und welche Auswirkungen die zukünftige Entwicklung in den einzelnen Bereichen hat. Bei Sourcery neigen wir dazu, zu schauen Komplexität , Arbeitsgedächtnis und Methodenlänge als kritische Metriken bei der Betrachtung innerhalb einer Funktion oder Klasse – Sie können sich aber auch Dinge wie den Wartbarkeitsindex, die Dokumenten- und Testabdeckung, die Duplizierungsrate und viele andere ansehen.

Ähnlich wie beim problembasierten Ansatz können Sie der laufenden und zukünftigen Verlangsamung der Entwicklung aufgrund technischer Schulden eine relative Auswirkung verschiedener Bewertungen (oder einer Gesamtqualitäts- oder Gesundheitsbewertung) zuordnen. Untersuchungen haben gezeigt, dass eine starke negative Korrelation zwischen Dingen wie Komplexität und Geschwindigkeit sowie der Codequalität und dem Fehlerrisiko, der Wartungslast und mehr besteht.

Schauen wir uns ein Beispiel an: Schauen wir uns noch einmal die einfache vierteilige Codebasis an, die wir uns im Abschnitt über geschwindigkeitsbasierte Messung angesehen haben.

Wir können die problematischen Abschnitte dieses Projekts leicht in der Tabelle erkennen (rot hervorgehoben), und die Berechnung der Zinsschätzung ist relativ einfach: Fassen Sie einfach die Zinsauswirkungen der verschiedenen Komponenten zusammen.

Einige der Nachteile dieses Ansatzes sind:

• Sie müssen Schätzungen der Interessenauswirkungen für verschiedene Qualitätsmetriken definieren (ich möchte einige als Basis zusammenstellen, aber es wird ziemlich von der Codebasis abhängig sein). Um dies zu erreichen, sollten Sie sich wahrscheinlich eine geschwindigkeitsbasierte Messung ansehen und diese mit der Qualität verknüpfen.
• Qualitätsmetriken selbst sind unvollkommen und können variieren erheblich von Sprache zu Sprache .

Dieser qualitätsbasierte Messansatz ist der am wenigsten genaue der drei von uns untersuchten Ansätze – er ist jedoch sehr effektiv, wenn es darum geht, im Laufe der Zeit einen ganzheitlichen Blick auf verschiedene Bereiche Ihres Projekts zu werfen. Sie können diesen Ansatz mit dem gerade besprochenen problembasierten Ansatz kombinieren, um die Verfolgung spezifischer Probleme mit der Verfolgung allgemeiner Qualitäts- und Gesundheitsprobleme in jedem Abschnitt Ihres Projekts in Einklang zu bringen.

Blick auf die Codebasis-Interaktionshäufigkeit

Für alle drei dieser Ansätze müssen wir eine Möglichkeit haben, die Auswirkungen in verschiedenen Abschnitten unserer Codebasis anhand der Häufigkeit abzubilden, mit der wir diesen Abschnitt der Codebasis tatsächlich berühren. Wenn es einen Abschnitt unseres Projekts gibt, der ein Albtraum ist, den aber niemand mehr anfasst, dann hat das keinen großen Einfluss auf unsere laufenden technischen Schulden. Umgekehrt kann eine kleine, aber anhaltende Verlangsamung eines Abschnitts der Codebasis, zu dem jeden Tag beigetragen wird, sehr schnell zu großen Zeitverlusten führen.

Um dies zu berücksichtigen, müssen wir uns ansehen, wie oft zu jedem Bereich unseres Projekts Beiträge geleistet werden. Wir können hier verschiedene Ansätze verfolgen: Wir schauen uns die Git-Historie an, um zu verstehen, welcher Bereich im Großen und Ganzen am häufigsten berührt wird, und verwenden gezieltere Tools wie z Codeszene um besser verdauliche historische Beitragsdaten zu erhalten, oder um einen zukunftsorientierten Ansatz zu verfolgen, indem wir uns unsere bevorstehenden Pläne und Prioritäten ansehen, um zu verstehen, wo unser Team in den nächsten Monaten die meiste Zeit verbringen wird.

Unabhängig davon, wie wir die Daten erhalten, können wir dann eine Aufschlüsselung darüber erhalten, wie viel Prozent unserer Zeit wir mit der Interaktion mit den einzelnen Abschnitten unserer Codebasis verbringen werden. Wenn wir dies zusammen mit dem Zinsbeitrag, den wir bereits ermittelt haben, kombinieren, können wir nun genau sehen, um wie viel wir mit einer Verlangsamung rechnen, wenn wir uns künftig mit den einzelnen Abschnitten unserer Codebasis befassen.

Wir setzen unser Beispiel von vorhin fort: Wenn wir eine vorausschauende Sichtweise einnehmen würden und alle Projekte, an denen wir in den nächsten drei Monaten arbeiten würden, neu wären, könnten wir sicher abschätzen, dass dies die Zeitmenge ist, die in jedem Bereich der Codebasis aufgewendet wird ( Denken Sie daran, dass dies ein sehr einfaches Projekt ist):

Wir können dies nun mit den Zinsschätzungen aus unserem geschwindigkeitsbasierten Ansatz und unserem auf Qualitätsmetriken basierenden Ansatz zurückführen und eine gute Vorstellung davon bekommen, wo wir am meisten ausgebremst werden.

Hier verwenden wir die Geschwindigkeitsverlangsamungen, die wir bei der Arbeit an den Abschnitten B und C festgestellt haben, als wir uns früher mit geschwindigkeitsbasierten Messungen befassten, und berechnen daraus, wie viel Zeit wir in den nächsten drei Monaten aufgrund von technischen Schulden verlieren. Insgesamt gehen wir davon aus, dass mehr als 28 Entwicklermonate zusätzlichen Aufwand allein für die Schulden aufwenden werden. Ein wichtiger Punkt, der bei diesem Ansatz berücksichtigt werden muss, ist, dass es dabei um die relative Geschwindigkeit geht – die Basisprojekte werden also so behandelt, als hätten sie praktisch keine Schulden, was normalerweise nicht korrekt ist. Das andere Problem bei diesem Ansatz besteht darin, dass er Schwankungen des künftigen Schuldenniveaus, die wahrscheinlich auftreten werden, nicht berücksichtigt. Da sie jedoch schwer vorherzusagen sind, ist es einfacher, sie zu ignorieren.

Hier haben wir die typischen prognostizierten Verzögerungen basierend auf der Codequalität jedes Abschnitts ermittelt und diese auf die nächsten drei Monate hochgerechnet. Generell sehen wir deutlich geringere Schuldenauswirkungsprognosen als bei Verwendung der Geschwindigkeitsmethode. Dies liegt daran, dass die auf der Technologieverschuldung basierenden Verlangsamungsschätzungen niedriger sind als das, was wir im Geschwindigkeitsfall gesehen haben – in diesem Fall müssen wir möglicherweise etwas mehr kalibrieren! Genau wie bei der geschwindigkeitsbasierten Metrik werden hier zukünftige Änderungen der technischen Schulden nicht berücksichtigt – aber beide Schätzungen können uns dabei helfen, zu bestimmen, wie wir das Umschreiben und Refactoring der verschiedenen Abschnitte unseres Projekts priorisieren sollten.

Verwalten von Zinsen und Schulden

Wir haben uns ein paar verschiedene Möglichkeiten angesehen, um zu erklären, wie sehr sich unsere technischen Schulden dauerhaft auf uns auswirken, aber wir haben die Frage, was ein gesundes Maß an technischen Schulden ist, noch nicht vollständig beantwortet.

Leider gibt es keine wirklich genaue Zahl. Kurzfristig könnte es pragmatisch sein, Schulden zu akzeptieren. Aber auf lange Sicht wollen wir unsere Schulden nahe Null halten. Denn anhaltende Zinsen werden sich als sehr kostspielig erweisen und die Tech-Schulden bauen sich immer weiter auf. Aber wir wollen nicht unsere ganze Zeit damit verbringen, Probleme zu überarbeiten und neu zu schreiben, die uns nur geringfügige Vorteile bringen.

Wie bereits erwähnt, möchten wir im Allgemeinen keine Zeit damit verbringen, Bereiche der Codebasis anzusprechen, in denen:

Aber im Extremfall könnte es dazu kommen, dass wir durch eine hohe Verschuldung, deren Behebung äußerst kostspielig ist, massiv ausgebremst werden – was auch keine gute Situation ist.

Der beste Ansatz besteht darin, irgendwo in der Mitte zu landen. Nehmen Sie sich bei Ihrer laufenden Planung Zeit, um technische Schuldenprobleme anzugehen und vorhandenen Code umzugestalten – und priorisieren Sie dabei, was für Sie derzeit am kostspieligsten ist. Und treiben Sie das so lange voran, bis Sie feststellen, dass die Erträge aus dem Schuldenabbau deutlich sinken.