Themen

Motivation und Voraussetzungen

Wann sollte man refaktorieren?

Strategien und Vorgehen beim Refactoring

Zusammenhang mit Entwurfsmustern

Glossar

PDF

Kapitel bei Springer

https://link.springer.com/chapter/10.1007/978-3-662-71607-6_20

• Refactoring ist die Verbesserung der internen Struktur
  existierenden Codes ohne Änderung seiner Funktionalität.
• Zeitdruck ist kein Argument gegen Refactoring.
  Unterlassen verursacht später (erheblich) mehr Aufwand.
• Refactoring ist eine Frage der Professionalität.
  Es sollte langsam, wohlüberlegt und sorgfältig umgesetzt werden.
• Gute Tests und eine ausreichende Testabdeckung
  sind zwingende Voraussetzung für erfolgreiches Refactoring.
• Gute IDEs unterstützen auch komplexere Refactoring-Schritte
  und steigern so die Produktivität und Codequalität.

Refactoring ist die Verbesserung der internen Struktur existierenden Codes, ohne dabei seine Funktionalität zu verändern – und damit die Antwort darauf, wie man Code davor bewahren kann, immer unlesbarer und schlechter wartbar zu werden (Software-Entropie). Genauso ist Refactoring eine – wenn nicht die einzige funktionierende – Strategie, existierenden Code weiter zu pflegen und zu entwickeln. Wir fangen so gut wie nie von vorne an – und können uns das meist auch gar nicht leisten. Refactoring ist also die Antwort darauf, wie sich all die bislang unter der Überschrift „Sauberer Code“ behandelten Aspekte in der Realität umsetzen lassen: Schritt für Schritt und jeweils im lokalen Kontext.

Entscheidend für Refactoring neben einer ausreichenden Testabdeckung und einer Versionsverwaltung ist die persönliche Einstellung: Refactoring muss Teil des Programmieralltags sein, nichts, für das wir uns gesondert Zeit nehmen (und das dann nie tun). Refactoring ist Mittel zum Zweck: Code will gelesen und verstanden werden, Code will erweitert und angepasst werden. Deshalb werden sich konkrete Refactoring-Schritte meist auch auf einen lokalen Kontext beschränken. Außerdem ist Refactoring der entscheidende dritte Schritt im Zyklus der testgetriebenen Entwicklung, ohne den dieser Ansatz zum Scheitern verurteilt ist.

Der „große Neuentwurf“ ist fast immer zum Scheitern verurteilt: Es fehlt die Zeit, der Komplexitätsgrad der Fragestellung ist viel zu groß, um „schnell mal“ etwas zu implementieren, und vielleicht am Wichtigsten: Solange diejenigen, die die Software implementieren, sich und ihre Gewohnheiten nicht ändern, wird das Ergebnis des Neuschreibens kaum besser sein. Übernimmt ein neues Team, wird es auch nicht besser, weil dem in der Regel die jahrelange Erfahrung der Vorgänger fehlt und sie (fast) alle Fehler noch einmal machen.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, es werden aber keine Antworten zur Verfügung gestellt.

• Was ist Refactoring?
• Wann sollte man Code refaktorieren, wann nicht?
• Was ist ein wesentlicher Aspekt von Refactoring?
• Warum ist Refactoring so wesentlich für gleichbleibend hohe Codequalität?
• Was sind zwingende Voraussetzungen für erfolgreiches Refactoring?
• Nennen Sie mindestens drei Beispiele für konkrete Refactoring-Schritte auf unterschiedlichen Ebenen von Code.
• Warum ist Refactoring in fast allen Fällen dem kompletten Neuentwurf vorzuziehen?
• Welche Gemeinsamkeiten können Sie zwischen Refactoring und guter wissenschaftlicher Praxis erkennen?
• Welche Rolle spielen IDEs für das Refactoring? Welches Qualitätskriterium für IDEs lässt sich daraus ableiten?

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Der „Klassiker“ zum Thema ist ist das Buch von Martin Fowler {[fowler-m-1999]}. Es entstand, bevor testgetriebene Entwicklung wirklich populär wurde, verweist aber gleichwohl auf die Notwendigkeit sauberer Unittests und einer hohen Testabdeckung als Voraussetzung für erfolgreiches Refactoring. (Darüber hinaus ist Fowler schon damals mit dem Konzept der testgetriebenen Entwicklung vertraut.) Fowler bringt gleich am Anfang des Buches ein ausführliches, schrittweises Beispiel, so dass man ihm geradezu beim Refactoring zusehen kann.

Eine gute Zusammenfassung von Refactoring findet sich in Kapitel 25 von {[mcconnell-s-2004]}. McConnell fasst hier viele der Strategien aus {[fowler-m-1999]} sehr knapp zusammen.

Von Robert Martin gibt es unterschiedlich ausführliche Beschreibungen von Refactoring anhand konkreter Codebeispiele, eher kurz ist Kapitel 5 in {[martin-rc-2003]}, ausführlicher Kapitel 14 in {[martin-rc-2008]}. Sehr knapp und ohne Beispiele ist Abschnitt 33 in {[hunt-a-1999]}. Wer eine deutsche Beschreibung vorzieht, wird in Kapitel 15 von {[passig-k-2013]} fündig.

Der Zusammenhang zwischen Entwurfsmustern {[gamma-e-1995]} und Refactoring {[fowler-m-1999]} wird von Kerievsky {[kerievsky-j-2005]} hergestellt. Er präsentiert in seinem Buch einen Katalog von Refactorings zu, in Richtung von und weg von Entwurfsmustern.

Die Frage der „richtigen“ Metapher für das Programmieren wird von vielen Autoren diskutiert. Hunt und Thomas {[hunt-a-1999]} betonen sehr den handwerklichen Aspekt. Ein sehr lesenswerter Essay zum Verhältnis von Ingenieurswissenschaften und Softwareentwicklung, insbesondere hinsichtlich des Wesens von Code als Entwurf, ist „What Is Software Design“ von Jack W. Reeves, abgedruckt im Anhang von {[martin-rc-2003]}. Wieder einen anderen Aspekt, nämlich den der Kunst, betonen Donald Knuth mit seinem monumentalen Werk „The Art of Computer Programming“ und in seiner Nachfolge Raymond {[raymond-es-2004]} und Graham {[graham-p-2010]}, letzterer insbesondere in seinem titelgebenden Essay „Hackers and Painters“.

Aktuell (im November 2018) ist das Buch „Refactoring“ von Martin Fowler in einer zweiten Auflage erschienen. Dazu gibt es ein Interview auf Heise.de mit Martin Fowler.

<bibtex bibliography> sort=true </bibtex>