5000 Zeilen Copy & Paste

Diese Geschichte handelt von einem Fehler, den man am Anfang nicht als Fehler erkennt, weil er wie das Gegenteil aussieht: wie Vorsicht. Sie ist bewusst allgemein gehalten — ohne System, ohne Beteiligte, ohne Zeitpunkt. Was bleibt, ist die Lektion, und die gilt weit über den einen Fall hinaus.

Situation

In einer gewachsenen Codebasis gab es eine wiederkehrende Aufgabe, die an vielen Stellen erledigt werden musste. Beim ersten Mal wurde sie geschrieben. Beim zweiten Mal wurde sie kopiert. Beim dritten Mal war Kopieren schon die Gewohnheit. Über die Zeit sammelte sich so ein Bestand von rund 5000 Zeilen nahezu gleichen Codes an, verteilt über das ganze System — jede Kopie ein wenig angepasst, keine ganz wie die andere.

Ausgangsannahmen

Die Annahme dahinter war nicht Faulheit, sondern eine bewusste, vertretbare Haltung: Kopieren ist sicher. Jede Kopie ist unabhängig; eine Änderung hier kann dort nichts brechen. Eine gemeinsame Abstraktion dagegen wäre eine Wette darauf, dass all diese Stellen wirklich dasselbe meinen — und eine falsche Abstraktion ist teurer als Duplikation. Solange die Form der Sache nicht klar war, schien Warten die richtige Entscheidung. Bis dahin ist diese Haltung sogar korrekt.

Problem

Mit der Zeit kehrte sich das Verhältnis um. Was als Sicherheit gedacht war, wurde zur Last. Sollte sich die gemeinsame Regel ändern, musste man sie in vielen Kopien zugleich ändern — und fand nie sicher alle. Die Kopien liefen auseinander: Ein Fix an einer Stelle erreichte die anderen nicht, und dieselbe Aufgabe verhielt sich je nach Kopie unterschiedlich. Aus „unabhängig" war „inkonsistent" geworden, ohne dass ein einzelner Tag den Umschlag markiert hätte.

Ursache

Die eigentliche Ursache war nicht die Duplikation selbst — Duplikation ist ein legitimes Werkzeug. Die Ursache war ein übersehenes Signal. Duplikation ist günstig, solange die Kopien wirklich unabhängig sind und sich getrennt entwickeln. Sie wird teuer in genau dem Moment, in dem die Kopien anfangen, sich gemeinsam zu ändern — denn dann sind sie keine zufällig ähnlichen Codestücke mehr, sondern eine einzige Regel in vielen Fassungen. Dieses Signal war da: Die Stellen änderten sich immer zusammen, und sie drifteten auseinander. Der Fehler war, es zu lange nicht als das zu lesen, was es war.

Entscheidung

Die Entscheidung fiel, als die Form endlich klar war — und gerade weil sie klar war. Die vielen Kopien hatten über die Zeit die wahre Gestalt der gemeinsamen Regel sichtbar gemacht, die man früher nur hätte erraten können. Jetzt gab es keine Wette mehr: Die Abstraktion war nicht mehr vorzeitig, sondern belegt. Also wurde konsolidiert — die gemeinsame Aufgabe bekam einen einzigen, klaren Ort.

Umsetzung

Der Umbau geschah nicht in einem Sprung, sondern in kleinen, umkehrbaren Schritten. Zuerst wurde die tatsächliche Gemeinsamkeit herausgeschält — das, was alle Kopien wirklich teilten, getrennt von dem, was nur zufällig gleich aussah. Diese Gemeinsamkeit wurde genau einmal ausgedrückt, hinter einer klaren Grenze. Dann wurde Kopie für Kopie darauf umgestellt, jede mit dem Anspruch, das Verhalten unverändert zu lassen, bevor irgendetwas verbessert wurde. Am Ende war der Bestand um etwa 90 Prozent kleiner — dieselbe Fähigkeit, an einem Ort statt an vielen.

Trade-offs

Die Konsolidierung ist nicht gratis, und sie ist nicht immer richtig. Die eine Abstraktion muss nun gepflegt werden; sie bündelt, was vorher verstreut war, und macht die eine Stelle wichtig. Der Preis der frühen Duplikation — das Warten — war die bewusste Gegenleistung dafür, nicht die falsche Abstraktion zu bauen, die teurer gewesen wäre als jede Kopie. Anders hätten wir entschieden, wenn die Kopien wirklich unabhängig geblieben wären: Dann wäre Zusammenführen ein Fehler gewesen, der Dinge koppelt, die getrennt gehören.

Was wir gelernt haben

Die Lektion ist nicht „nie kopieren" und nicht „immer abstrahieren". Beides sind Dogmen, und Dogmen ersetzen das Denken. Die brauchbare Frage lautet: Müssen diese Stellen sich gemeinsam ändern? Solange die Antwort nein ist, ist Duplikation günstig und ehrlich. Sobald die Antwort ja wird — sobald die Kopien anfangen, zusammen zu wandern —, ist der Zeitpunkt zum Abstrahieren gekommen, und dann sollte man es entschieden tun. DRY zielt auf Wissen, das zusammengehört, nicht auf Zeilen, die zufällig gleich aussehen. Der Fehler lag nie im Kopieren; er lag darin, den Umschlag nicht zu bemerken.

Wie das Batunet verändert hat

Seither behandeln wir „Don't Repeat Yourself" nicht als Regel, sondern als Frage — und stellen sie in Reviews bewusst: Ändert sich das hier gemeinsam? Wir kopieren ohne schlechtes Gewissen, solange die Kopien unabhängig sind, und wir achten auf das Signal, dass sie es nicht mehr sind. Aus einem übersehenen Umschlag ist eine Gewohnheit geworden, hinzusehen. Das ist der Wert einer Lektion, die man selbst bezahlt hat: Sie wird Teil dessen, wie man arbeitet.

Weiterführend

• Guide: Software, die in zehn Jahren noch läuft — warum Kopplung und Änderbarkeit über die Lebensdauer entscheiden.
• Decision: Modularer Monolith als Ausgangspunkt — Struktur hinzufügen, wenn ein Problem sie verlangt, nicht vorher.
• Playbook: Einen Legacy-Monolithen modernisieren — konsolidieren in kleinen, umkehrbaren Schritten.
• Opinion: Warum vorzeitige Abstraktion Komplexität schafft — die falsche Abstraktion ist teurer als Duplikation.
• Glossar: DRY (Don't Repeat Yourself) — Wissen einmal darstellen, nicht Zeilen.

Gute Lektionen fühlen sich im Nachhinein selbstverständlich an. Der Wert liegt nicht darin, sie zu kennen, sondern den Moment zu erkennen, in dem sie greift.