Wenn Features, die frueher zwei Tage dauerten, ploetzlich zwei Wochen brauchen, ist Refactoring faellig.
Refactoring ist kein Neustart. Es ist eher chirurgische Arbeit an einem laufenden System.
Wann Refactoring wirklich ansteht: wenn kein Teammitglied mehr erklaeren kann, warum eine bestimmte Klasse existiert, wenn neue Entwickler drei Wochen brauchen, um ueberhaupt beizutragen, oder wenn Bugfixes zuverlaessig neue Bugs produzieren. Diese Signale sind kein Zeichen von Schwaeche, sondern normale Folge von Wachstum ohne ausreichende Pflege.
Das Strangler-Fig-Pattern
Die Idee dahinter: neuen Code parallel zur bestehenden Loesung aufbauen und den alten Code sukzessive abloesen, wie ein Feigenbaum, der um einen anderen waechst und ihn langsam ersetzt. Das ist deutlich risikoaermer als ein Big-Bang-Rewrite und liefert waehrenddessen weiter Wert.
Safety Net zuerst
Vor jedem Refactoring stehen Tests, nicht aus TDD-Ueberzeugung, sondern weil man ohne Tests nicht erkennt, ob etwas kaputtgegangen ist. Code ohne Tests ist Code, den man vorerst nicht anfassen sollte, erst Coverage aufbauen, dann anfassen.
Was bei Apps besonders zu beachten ist
Plattform-spezifischer Code ist oft besonders verheddert, Lifecycle-Management, Background Tasks, Plattform-Channels sind die Bereiche, in denen technische Schulden am teuersten werden. Und State Management verdient einen genauen Blick: Wenn der App-State global, unstrukturiert und von ueberall beschreibbar ist, ist das oft der beste Ausgangspunkt fuers Aufraeumen.
Checkliste: Betroffene Bereiche identifiziert und priorisiert, Tests fuer kritische Bereiche vor Refactoring geschrieben, Strangler-Pattern statt Big Bang gewaehlt, Refactoring in kleinen, pruefbaren Schritten, Code Reviews eingeplant, Performance vorher und nachher verglichen.
Ein Beispiel aus der Praxis
Eine gewachsene App hatte ueber drei Jahre hinweg fuenf verschiedene Ansaetze fuer die Netzwerkkommunikation angesammelt, je nachdem, wer das jeweilige Feature gebaut hatte. Statt alles auf einmal zu vereinheitlichen, wurde ein einziger, sauberer Networking-Layer neu gebaut und ausschliesslich fuer neue Features verwendet. Bestehender Code wurde erst angefasst, wenn ohnehin an ihm gearbeitet wurde. Nach etwa einem Jahr war der Grossteil der App migriert, ohne dass jemals ein dedizierter „Migrations-Sprint“ noetig war, der den Feature-Fortschritt gebremst haette.
Eure App ist schwer wartbar geworden? markom.digital uebernimmt strukturierte Refactoring-Projekte, mit klarem Plan und messbarem Fortschritt.
