Refactoring vs. Rewriting

Wann sollte man ein System von Grund auf neu entwickeln? Wann genügt es die bereits bestehenden Komponenten auf den neuesten Stand zu bringen? Vermutlich hat sich jeder Entwickler schon einmal diese Frage gestellt. Beide Varianten bringen gewisse Vor- und Nachteile mit sich.

Wenn ein Projekt über mehrere Jahre besteht, ist es ganz natürlich, dass verschiedene Mitarbeiter am Code beteiligt sind. Nachdem vermutlich jeder Entwickler seinen eigenen Stil hat Code zu schreiben, kann es schnell unübersichtlich werden. Fremden Code zu lesen und auch zu verstehen ist oft schwieriger als diesen selbst zu schreiben. Steht nun eine große Änderung oder Erweiterung an, stellt sich die Frage, der so ziemlich jeder Entwickler schon einmal gegenüberstand: Refactoring oder Rewriting? Also, versuche ich den derzeitigen Code zu überarbeiten und auf den neuesten Stand zu bringen oder schreibe ich alles neu und fange von vorne an, bevor ich die neuen Änderungen hinzufüge. Diese Entscheidung ist oft nicht leicht zu treffen, da mehrere Faktoren mitspielen.

Refactoring

Refactoring ist eine disziplinierte Technik bestehenden Code zu verbessern und seine interne Struktur zu verändern. Das Verhalten muss dabei jedoch immer dasselbe bleiben. Beim Refactoring ist es schwieriger oder oft unmöglich, Technologien oder Frameworks grundlegend zu ändern. Wenn alle Basisfunktionalitäten auf einem bestimmten Framework basieren, kann es viel Zeit benötigen diese zu verändern oder upzudaten. Das hängt unter anderem damit zusammen, wie lange nicht mehr am Projekt gearbeitet wurde oder seit wann das Projekt überhaupt besteht. Bei älteren Systemen kann das sehr problematisch sein.

Eine der größten Herausforderungen beim Refactoring besteht darin, dass das System nach außen hin nach den Änderungen genauso funktionieren sollte wie zuvor. Das Ziel des Refactorings besteht darin, Änderungen am Code vorzunehmen, die im Laufe der Zeit die Gesamtqualität der Codebasis verbessern und Weiterentwicklungen im Laufe der Zeit erleichtern.

Ein Projekt, das mehrere Jahre alt ist und daher auch die Technologien der damaligen Zeit verwendet, ist nur schwer auf den neuesten Stand zu bringen. Da sich die Technologien und Trends in vielen Entwicklungsbereichen sehr schnell ändern, kann oft nicht mehr auf neue Features oder wichtige Fixes zugegriffen werden.
Hat man das Refactoring allerdings abgeschlossen, steht dem Einsatz neuer Technologien natürlich nichts mehr im Wege – im Ausmaß der Basisfunktionalitäten versteht sich. Einer der Vorteile gegenüber des Rewritings ist, dass es möglich ist, weiterhin Updates (nicht nur Bug Fixes) an die Benutzer zu liefern, während nebenbei die Systemcode-Basis verbessert wird. Für den Entwickler selbst ist es oft interessanter und spannender neue Technologien auszuprobieren.

Der wohl größte Vorteil des Refactorings ist der Zeitfaktor. Die Zeit, die man für Refactoring benötigt, wird wohl in 99% der Fälle kürzer sein als das System von Grund auf neu zu entwickeln.

Rewrite

Auf der anderen Seite gibt es die Möglichkeit eines „Rewrites“ des ganzen Systems. Wie der Name schon sagt, wird hierbei das ganze System neu geschrieben. Der Entwickler hat hierbei freie Handlungsmacht bezüglich der Umsetzung. Von den verwendeten Technologien und bestimmten Frameworks bis hin zur Architektur des Systems – der Entwickler kann selbst entscheiden, wie er das System zusammensetzt. Aus diesen Gründen tendieren Programmierer in der Regel dazu, den Code neu zu schreiben anstelle ein Refactoring veralteter Systeme anzustreben. Im Normalfall ist die Motivation für die Entwickler auch größer, etwas völlig Neues zu entwickeln.

Dennoch ist das Neuschreiben eines Systems sehr oft problematisch. Zu allererst kostet das Entwickeln eines neuen Systems jede Menge Zeit. In der Zeit, die man für das Neuschreiben des Systems braucht, fällt man für andere Wartungs- beziehungsweise Entwicklungsarbeiten aus, für die einen das Team eingeplant hätte. Das kostet wiederum mehr Geld als geplant.

Je nach Größe des Projekts wird es für einen einzelnen Entwickler auch nicht möglich sein, das ganze Projekt alleine umzusetzen. Viele Features sind oft über Jahre entwickelt worden. Neuschreiben bedeutet, dass diese langjährig entwickelten und gewarteten Features in kürzester Zeit nachimplementiert werden müssen. Es fühlt sich vom ersten Tag so an, als wäre man mit dem Projekt hinterher, was zusätzlichen Druck auf die Mitarbeiter ausübt.

Des Weiteren gibt es in jedem Projekt dunkle Codeabschnitte, für die weder eine Dokumentation noch Tests vorhanden sind, von denen aber mehrere Features abhängig sind, und bei der kleinsten Änderung das System nicht mehr so funktioniert wie sie sollten. Diese müssen also verstanden, verbessert und nachgebaut werden, was wiederum zeitaufwändig ist. Außerdem muss parallel das alte System am Leben gehalten und regelmäßig gewartet werden, da ja der Kunde darauf angewiesen ist.

Fazit

Welche der beiden Methoden wirklich besser ist, ist sehr schwierig zu entscheiden. Nicht umsonst gibt es seit Jahren Diskussionen, Befürworter und Gegner beider Varianten. Ich denke es sollte in den meisten Fällen eine strategische Entscheidung sein. Wie oben erwähnt, spielen viele Faktoren mit und die Entscheidung hängt auch unter anderem mit Kriterien wie der Größe der Anwendung, der Größe der Nutzerbasis und dem aktuellen Status des Codes ab. Es ist in den meisten Fällen nicht der Entwickler alleine, der solch eine Entscheidung treffen kann. Das ganze Umfeld, das Team, der Kunde und weitere Stakeholder spielen hierbei wichtige Rollen. Je größer die Anwendungen sind, desto mehr Zeit wird für den Rewrite des Systems benötigt. Daher bietet sich oft das Refactoring an, solange alle Anforderungen mit dem derzeitigen Technologiestand erfüllt werden können.