Refactoring von Spaghetticode ist grundsätzlich anders, als Refactoring im Rahmen testgetriebener Entwicklung: Letzteres ist gut verstanden und bedarf keiner besonderen Beachtung während der Planung, die einzelnen Refactoringschritte dauern immer nur ein paar Minuten und sind in der Gesamtschätzung enthalten.

Wenn man aber versucht, alten Spaghetticode durch Refactoring wieder in einen wartbaren Zustand zu bringen, sieht die Sache ganz anders aus. Dies ist ein kaum planbares Unterfangen mit hohem Zeit- und Aufwandsrisiko. Der Nutzen kommt dabei häufig erst, wenn die Arbeiten deutlich voran geschritten sind; oft wird also Monate lang ohne greifbaren Nutzen entwickelt, bis sich der „Knoten“ plötzlich auflöst und ein deutlich besser wartbares Design entsteht, das exakt der alten Funktionalität entspricht – modulo der Fehler, die man üblicherweise während dieser Arbeit noch entdeckt und behebt.

Um die Situation etwas zu entschärfen, gehen wir bei solchen Vorhaben oft in mehreren Phasen vor, die sich bisher ganz gut bewährt haben (ich spreche hier von „wir“, weil ein solcher Umbau immer im Team oder mindestens von einem Paar durchgeführt werden muss, niemals von einem „Einzelkämpfer“):
Weiterlesen →