Refactoring

Refactoring behält das bestehende Verhalten bei, eine Neuentwicklung ersetzt es. Beim Umbau bleibt die über Jahre gewachsene Fachlogik samt ihrer undokumentierten Sonderfälle erhalten; beim Neubau muss jeder dieser Sonderfälle erst wiedergefunden werden, und was niemand findet, fehlt anschließend. Die Entscheidungsregel lautet deshalb: Stimmen die fachlichen Regeln und ist nur ihre Anordnung im Code schlecht, ist Refactoring der Weg. Sind die Regeln selbst falsch, ändert kein Umbau daran etwas – dann ist eine Neuentwicklung fällig.

Refactoring macht Software weder schneller noch fehlerfrei und liefert kein neues Merkmal. Wer nach einer Umbaurunde eine sichtbare Verbesserung erwartet, wird enttäuscht: Nach außen ist alles wie vorher – das ist die Definition, nicht ein Versäumnis. Der Gewinn zeigt sich erst bei der nächsten Änderung an derselben Stelle, und nur dort. Auch vorhandene Fehler verschwinden nicht nebenbei; ein Umbau verschiebt sie mit, nur besser sortiert. Behoben werden sie in einem eigenen Schritt.

Im Regelfall das Entwicklungsteam, und zwar ohne Rückfrage, solange der Umbau keinen Termin verschiebt. Sobald er das tut, ist es keine technische Entscheidung mehr, sondern eine über Reihenfolge und Zeit – und die gehört dem Auftraggeber. Die Probe lautet: Lässt sich das Refactoring im selben Arbeitsschritt abschließen und rückstandslos zurücknehmen, entscheidet das Team. Zieht es eine eigene Abnahme nach sich, entscheidet der Kunde. Ohne diese Trennung entstehen Umbauten, die niemand bestellt hat.

So weit, wie Compiler oder Typprüfung mitlesen, und keinen Schritt weiter. Eine Umbenennung in der Entwicklungsumgebung erreicht jede Stelle, die das Symbol als Symbol verwendet. Sie erreicht nicht, was als Zeichenkette irgendwo steht: Feldnamen in Vorlagen, Spaltennamen in der Datenbank, Übersetzungsschlüssel, Einträge in gespeicherter Konfiguration, dynamisch zusammengesetzte Aufrufe. Bei übernommenen Projekten finden wir regelmäßig genau solche Reste – eine sauber umbenannte Methode und daneben eine Vorlage, die weiter den alten Namen ruft.

Rund 17,3 von 41,1 Wochenstunden, also 42 Prozent, gerechnet aus beiden Angaben. Die Werte stammen aus der Studie „The Developer Coefficient“ von Stripe und Harris Poll, September 2018; befragt wurden über 1.000 Entwickler und über 1.000 Führungskräfte in fünf Ländern, darunter Deutschland. Auf technische Schulden allein entfielen 13,5 Stunden. Erhoben wurde per Selbstauskunft, nicht gemessen – die Größenordnung trägt, die Nachkommastelle nicht.

Darauf, dass es dort keines mehr ist. Sobald ein Name nach außen sichtbar wird – als Adresse, als Feld einer Programmierschnittstelle, als Spalte in einer fremd genutzten Datenbank –, verändert seine Umbenennung das Verhalten für alle, die ihn aufrufen. Das ist ein Bruch, kein Umbau. Der übliche Weg führt über eine Übergangszeit: Alter und neuer Name antworten parallel, der alte gilt als veraltet, und erst wenn ihn niemand mehr nutzt, fällt er weg.