20. Refactoring

Themen: Motivation und Voraussetzungen; Warum und wann sollte man refaktorieren?; Strategien und Vorgehen beim Refactoring; Zusammenhang mit Entwurfsmustern
Folien: PDF

Zentrale Aspekte

Software wird und muss sich immer wieder verändern,
da sich die Anforderungen ändern.
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 sollte langsam, wohlüberlegt und
sorgfältig durchgeführt werden.
Gute Tests und eine ausreichende Testabdeckung sind
zwingende Voraussetzung für erfolgreiches Refactoring.

Weiterführende Literatur

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.)

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.