Technische Schulden hängen nicht davon ab, wer den Code geschrieben hat, sondern davon, wie viel es kostet, ihn zu ändern. Ein fehlerfreies Modul, das niemand im Team versteht, stellt eine technische Schuld dar, da jede zukünftige Änderung die Überarbeitung der zugrundeliegenden Logik erfordert, die niemand geschaffen hat.
Dies ist heute wichtiger denn je, da sich ein schneller Weg zur Anhäufung von korrektem, aber missverstandenem Code herausgebildet hat: die Akzeptanz dessen, was ein Modell generiert, ohne zu verstehen, warum es so ist, wie es ist.
Wenn ein Team ein System modifiziert, besteht die eigentliche Arbeit nicht darin, neue Codezeilen zu schreiben. Vielmehr geht es darum, drei Fragen zu beantworten, bevor man sie schreibt: Was bewirkt dies aktuell? Warum wird es so implementiert? Und was wird kaputtgehen, wenn ich es ändere?.
Diese Arbeit nennt man Verständnis, und sie beansprucht den größten Teil der Zeit, die mit jeder Änderung an einem ausgereiften System verbunden ist. Wenn niemand den Code bei seiner Einführung verstanden hat, verschwindet das Problem nicht: Es wird lediglich aufgeschoben und mit Zinsen bezahlt, da derjenige, der es bezahlt, den Kontext der ursprünglichen Diskussion nicht kennt.
Es besteht eine unangenehme Asymmetrie: Generieren geht schneller als Verstehen.. Ein Modell kann in Sekundenschnelle etwas erzeugen, dessen Verständnis einen Menschen zwanzig Minuten kostet. Wenn die Generierung sich beschleunigt, das Verständnis aber nicht, häuft sich dieses Ungleichgewicht im Datenbestand an.
Niemand weiß, ob ein Teil verwendet wird. Es taucht Code auf, der möglicherweise notwendig ist, und im Zweifelsfall wird er beibehalten. Das System bläht sich mit Daten auf, die niemand zu löschen wagt.
Die Rezensionen werden oberflächlich. Wenn größere Änderungen häufig auftreten, verschiebt sich der Überprüfungsprozess von «Ich verstehe das und stimme zu» zu «Das erscheint vernünftig». Es ist eine stille, aber entscheidende Veränderung.
Die gleichen Probleme werden zweimal gelöst. Es tauchen drei Funktionen auf, die fast dasselbe tun, weil niemand wusste, dass die anderen existieren.
Fehler werden durch Umwickeln, nicht durch Reparieren behoben. Anstatt das Problem zu lösen, wird eine zusätzliche Bedingung hinzugefügt, weil es beängstigend ist, das Original anzufassen.
GitClear quantifizierte das dritte Symptom: Doppelte Codeblöcke hatten sich bis 2024 verachtfacht, und ihr nachfolgender Bericht zeigte, dass die Duplizierung weiter zunahm. Duplizierung ist ein statistisches Kennzeichen von Missverständnissen: Man kopiert, was man nicht gut genug versteht, um es effektiv wiederzuverwenden.
Wir schlagen nur eine Variante vor, und sie ist in jedem Team leicht zu verteidigen:
Niemand integriert Code, den er nicht auf einem Whiteboard erklären könnte.
Es ist nicht erforderlich, jedes Detail der Implementierung zu verstehen. Es genügt, drei Fragen beantworten zu können: Welches Problem löst es? Warum wurde es auf diese und nicht auf eine andere Weise gelöst? Und was würde geschehen, wenn es nicht mehr existieren würde?.
Bei korrekter Anwendung verlangsamt diese Regel den Prozess nicht, sondern ordnet ihn neu. Die Erstellung des 80%-Codes mit Unterstützung ist weiterhin gültig. Nicht mehr gültig ist es jedoch, ihn zu verwenden, ohne ihn vorher gelesen zu haben.
|
Üben |
Vor |
Mit künstlicher Energieerzeugung |
|---|---|---|
|
Größe der Änderung |
Begrenzt durch die zur Verfügung stehende Zeit zum Schreiben |
Es kann ohne natürliche Grenzen wachsen. |
|
Schwerpunkt der Rezension |
Fehler finden |
Prüfen Sie das Verständnis und die Passform. |
|
Hauptrisiko |
Ein spezifisches Versagen |
Eine Struktur akzeptieren, über die niemand entschieden hat |
|
Wirksame Kontrolle |
Peer-Review |
Änderung der Größenbeschränkung und obligatorischer Tests |
Die Zeilengröße erklärt DORAs Ergebnis von 2024: Mit zunehmender Nutzung von KI sank die Stabilität der Auslieferung um 7,21 Tsd. 3 Billionen. Die Ursache liegt nicht in der Qualität des generierten Codes, sondern im Wegfall des natürlichen Anreizes, ihn selbst zu schreiben. Eine tausendzeilige Änderung wird nicht auf dieselbe Weise geprüft wie eine fünfzigzeilige, egal wie gut der Prüfer ist.
Daher ist die wirksamste Kontrolle kein Werkzeug, sondern ein Prozessstandard: die Größe der Änderungen begrenzen. Es ist unkompliziert und es funktioniert.
Tests, die von einer Person verfasst wurden. Es ist sinnvoll, dass das Modell die Implementierung generiert; ebenso sinnvoll ist es, dass es den Test generiert, der diese Implementierung validiert und somit den Kreislauf schließt. Der Test muss ausdrücken, was das Unternehmen erwartet, und das kann nur eine Person wissen.
Dokumentation der Entscheidung, nicht des Codes. Es ist nicht nötig, jede Zeile zu kommentieren. Erforderlich ist ein Absatz, der erläutert, warum dieser Ansatz gewählt und welche Alternative verworfen wurde. So kann die Vorgehensweise innerhalb eines Jahres geändert werden, ohne die Analyse wiederholen zu müssen.
Eine Größenbeschränkung pro Wechselgeld. Jede vernünftige Grenze ist geeignet. Ihr Wert liegt nicht in der Zahl selbst, sondern darin, dass sie die Arbeit in verständliche Einheiten zerlegt.
Alle drei sind kostengünstig und erfordern keine neuen Werkzeuge. Es ist dieselbe grundlegende Logik, die den technischen Standards zugrunde liegt, die wir bei jeder Lieferung anwenden: explizite Verträge, isolierte Umgebungen und die Übergabe der Dokumentation an den Kunden, weil Der Quellcode und die dazugehörige Dokumentation sind Eigentum desjenigen, der dafür bezahlt.
Bei einer Prüfung gibt es eine Frage, die die Diagnose schneller ermöglicht als jede Kennzahl: Wählen Sie zufällig ein Modul aus und bitten Sie jemanden aus dem Team, zu erklären, warum es so gestaltet ist..
Wird eine schlüssige Erklärung geliefert, ist das System trotz seiner Mängel wartungsfähig. Lautet die Antwort jedoch, dass es funktioniert, ohne dass der genaue Grund dafür bekannt ist, werden die Kosten jeder zukünftigen Änderung höher ausfallen als bisher angenommen, und diese Differenz wird sich weiter vergrößern.
Das ist der wahre Indikator für technische Schulden. Nicht die Codezeilen, nicht das Alter, nicht das Werkzeug, mit dem es geschrieben wurde: die Diskrepanz zwischen dem, was das System leistet, und dem, was die Organisation darüber versteht.
Es handelt sich um die zusätzlichen Kosten, die bei jeder zukünftigen Änderung aufgrund von Entscheidungen entstehen, die zum damaligen Zeitpunkt getroffen wurden, um den Prozess zu beschleunigen. Sie werden nicht anhand des Alters des Codes oder seines Autors bemessen, sondern anhand der Kosten für dessen sichere Änderung.
Nicht etwa aufgrund der intrinsischen Qualität, sondern weil die natürliche Beschränkung des Schreibprozesses verloren geht: Änderungen werden immer umfangreicher, Revisionen oberflächlicher und Duplikate nehmen zu. GitClear dokumentierte, dass sich die Anzahl doppelter Blöcke bis 2024 verachtfacht hat.
Eine einfache Regel gilt: Niemand übernimmt Code, den er nicht an einem Whiteboard erklären könnte – welches Problem er löst, warum er so gelöst wurde und was passieren würde, wenn er nicht mehr existiert. Es ist nicht nötig, jedes Implementierungsdetail zu verstehen.
Drittens: schriftliche Bestätigung durch eine Person, in der die Erwartungen des Unternehmens dargelegt werden, Dokumentation der Entscheidung und der verworfenen Alternative sowie eine Größenbeschränkung pro Änderung, die eine Aufteilung der Arbeit in verständliche Einheiten erzwingt.
Denn Kopieren ist die übliche Reaktion, wenn man das Vorhandene nicht gut genug versteht, um es wiederzuverwenden. Jede Kopie erhöht die Anzahl der Stellen, an denen dieselbe Korrektur in Zukunft angewendet werden muss.
Man bittet ein Teammitglied, zu erklären, warum ein zufällig ausgewähltes Modul so aufgebaut ist. Ist die Erklärung schlüssig, ist das System trotz seiner Mängel wartbar; lautet die Antwort hingegen, dass es funktioniert und niemand den Grund dafür kennt, wird jede Änderung teurer als veranschlagt.
Wie gut versteht Ihr Team Ihr System heute? Wir prüfen Architektur, Code, Schulden und Sicherheit und liefern die schriftliche Diagnose innerhalb von 10 Werktagen zu einem Festpreis. Audit anfordern →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
