Paket 3

Refactoring und Technical Debt

Wir schreiben das System nicht von Grund auf neu. Wir bringen es in Etappen in Ordnung.

Jede Etappe hat einen eigenen Preis und ein messbares, im Vertrag festgehaltenes Ziel. Nach jeder Etappe läuft das System, und Sie können abbrechen — ohne abgebrochenes Projekt und ohne halbfertigen Umbau.

Unverbindlich anfragen
Symptome

Woran sich erkennen lässt, dass es so weit ist

Technical Debt meldet sich selten von selbst. Bemerkbar macht er sich meist über Termine.

Eine kleine Änderung dauert eine Woche

Eine Korrektur von einer Stunde erfordert den Test des halben Systems, weil die Abhängigkeiten nicht bekannt sind.

Niemand will ein bestimmtes Modul anfassen

Im Team gibt es einen Bereich, den man nur im äußersten Fall betritt. Meist denselben, der am häufigsten ausfällt.

Ein Bibliotheks-Update blockiert das Release

Die Abhängigkeiten sind so alt, dass das Anheben einer Version ein Dutzend weitere nach sich zieht.

KI-Code, den niemand gelesen hat

Er funktioniert, aber niemand kann sagen, warum er funktioniert oder was bei anderen Eingabedaten geschieht.

Ablauf

Messen, ändern, messen

Jede Etappe schließt mit einer eigenen Abnahme ab. Die Messung am Anfang und am Ende nehmen wir mit demselben Werkzeug in Ihrer Umgebung vor.

1AusgangsmessungZustand vor der Änderung 2Etappe 1Änderung und Abnahme 3Etappe 2Änderung und Abnahme 4Etappe 3Änderung und Abnahme 5Abschlussmessungdieselben Metriken Die Zahl der Etappen richtet sich nach dem Umfang. Nach jeder läuft das System, und die Zusammenarbeit kann enden.
Umfang

Was in den einzelnen Etappen geschieht

Messung des AusgangspunktsDen Ist-Zustand messen wir vor der ersten Änderung: Technical Debt und Komplexität in SonarQube, Testabdeckung, Antwortzeiten, Schwachstellen in den Abhängigkeiten. Ohne das lässt sich keine Verbesserung belegen.
SicherheitsnetzTests rund um den zu ändernden Bereich. Refactoring ohne Tests ist Umschreiben im Blindflug — so enden misslungene Umbauten in der Regel.
Aufräumen des CodesTrennung der Verantwortlichkeiten, Beseitigung von Duplikaten, Vereinfachung der Stellen mit der höchsten Komplexität. Änderungen in kleinen Schritten, jede einzeln zurücknehmbar.
Abhängigkeiten und SchwachstellenAktualisierung von Bibliotheken und Frameworks, Beseitigung bekannter Schwachstellen, Ordnung bei den Open-Source-Lizenzen.
PerformanceDort, wo die Messung ein tatsächliches Problem gezeigt hat: Datenbankabfragen, Speicherverbrauch, Antwortzeiten.
AbschlussmessungDieselben Metriken wie am Anfang, mit demselben Werkzeug erhoben. Die Differenz ist Gegenstand der Abnahme.
Vertrag

Messbare Ziele statt Absichtserklärungen

Für jede Etappe halten wir im Vertrag konkrete Werte fest. Die Abnahme besteht in der Prüfung, ob sie erreicht wurden — nicht in der Einschätzung, ob der Code besser aussieht.

Bewertung in SonarQube — die Kennzahlen für Technical Debt und Komplexität im benannten Bereich: Ausgangswert und Zielwert.
Testabdeckung — der Abdeckungsgrad für das Modul der jeweiligen Etappe, vorher und nachher mit demselben Werkzeug ermittelt.
Antwortzeit — für die Vorgänge, die Sie als wesentlich benennen, gemessen in Ihrer Umgebung.
Schwachstellen in den Abhängigkeiten — die Zahl der bekannten Schwachstellen im erfassten Umfang, vor und nach der Aktualisierung.

Was wir nicht versprechenProzentwerte nennen wir nicht vor der Messung des Ausgangspunkts. Die Zahlenziele legen wir nach der ersten Etappe fest, wenn der Ausgangszustand bekannt ist — und erst dann gehen sie in den Vertrag ein.

Fragen

Häufige Fragen

Müssen wir die Arbeit an neuen Funktionen anhalten?

Nein. Die Etappen legen wir so an, dass sie sich zwischen Releases einfügen lassen. Deshalb arbeiten wir bereichsweise und nicht am ganzen System auf einmal.

Was, wenn wir nach der ersten Etappe entscheiden, dass es genügt?

Dann endet es dort. Jede Etappe ist ein abgeschlossenes Ganzes mit eigener Abnahme und verpflichtet zu keiner weiteren.

Wäre es nicht günstiger, alles neu zu schreiben?

Fast nie. Eine Neuentwicklung bedeutet, sämtliche Geschäftsregeln nachzubilden, die sich über Jahre im alten Code angesammelt haben und von denen die meisten nirgends festgehalten sind. Das Aufräumen in Etappen dauert länger, aber das System läuft durchgehend.

Beginnen Sie mit einem Audit?

Mit der Messung des Ausgangspunkts, die einen engeren Umfang hat als ein vollständiges Audit. Wenn noch nicht klar ist, wo das Problem liegt, ist es sinnvoller, zu beginnen mit dem KI-Code-Audit.

Arbeiten Sie auf unserer Infrastruktur?

Ja. Repository, Umgebungen und Daten bleiben bei Ihnen. Wir arbeiten mit den Zugängen, die Sie uns erteilen, und geben sie nach Abschluss der Arbeiten zurück.

Wie setzen Sie KI-Werkzeuge ein?

Unter Aufsicht: Jeder Abschnitt durchläuft das Review eines zweiten Ingenieurs, bevor er weitergeht. Ihre Daten gelangen nicht in Prompts. Die Regeln haben wir im Dokument „Daten, DSGVO und KI-Werkzeuge“ beschrieben, das vor Arbeitsbeginn übergeben wird.

Das Modul, das niemand anfassen will

Sagen Sie uns, was die größten Schwierigkeiten bereitet. Die erste Einschätzung des Ausgangspunkts ist kostenfrei.

Unverbindlich anfragen