Man könnte Entwicklung auch beschreiben als kontinuierliches Refactoring. Einen Schritt vor, zwei zurück, drei vor... In kleiner Amplitude und hoher Frequenz ist das der gelebte Alltag jeden Entwicklers, und überschaubar.
Aber was ist mit den langen Wellen? Wir können den "richtigen Weg" erst erkennen, wenn wir auf einem anderen, verschlungenen, schon zum Ziel gelangt sind. Deshalb heisst es auch Entwicklung: Das Wissen, wie wir etwas bauen würden, haben wir erst, wenn unser Gebäude schon steht.
Aber dann ist es zu spät, um es nochmal und gut zu machen, wir müssen weiter. Der Releasedruck zwingt uns, Stockwerk auf Stockwerk zu setzen; Änderungen am Fundament werden immer unmachbarer, riskanter, unüberschaubarer. Bis die Risse nicht mehr zu übersehen sind, und das Risiko des Weitermachens sich steil dem Risiko einer Operation am Fundament annähert.
In solchen Situationen ist das radikale Refactoring der einzige Weg, sich aus einer Lage zu befreien, in der es zunehmend eng wird; wieder Luft zu gewinnen, und Zuversicht, dass das Produkt die Chance zur Evolution behält.
Radikale Refactorings müssen gut vorbereitet sein, es sind Operationen am offenen Herzen. Sie müssen mit großer Klarheit, Präzision, geringstem Risiko und höchster Geschwindigkeit durchgeführt werden, um den Fluß der Entwicklung nicht zu gefährden.
Das erfordert eine Strategie:
Was tauschen wir? warum? wogegen?
Wie lässt es sich partitionieren? Wo Branch, wo Merge?
Und schließlich entscheidend:
Wie wissen wir, daß wir fertig und erfolgreich sind?
Das Refactoring steht und fällt mit einem klugen, tiefen und vollständigen Satz an Tests. Mit ihnen wird es ein furioser Handstreich, ohne sie ist es ein Himmelfahrtskommando.