Martin Fowler: Refactoring

Martin Fowler: Refactoring

Martin Fowler
Mit Beiträgen von Kent Beck
Übersetzung: Dr. Jan Linxweiler, Knut Lorenzen
Refactoring: Wie Sie das Design bestehender Software verbessern

2. Auflage
2020, 472 Seiten, Broschur
mitp-Verlag
ISBN: 978-3-95845-941-0

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Refactoring als Instrument zur Verbesserung des Codes nachdem dieser geschrieben wurde, war und bleibt von großer Wichtigkeit. Martin Fowlers Buch Refactoring: Wie Sie das Design bestehender Software verbessern, befasst sich mit ebendiesem Thema: was ist Refactoring, wann und wie kann es am Besten eingesetzt werden. Ein Katalog, welches die gängigsten Refactorings beschreibt und als Nachschlagwerk konzipiert ist, macht dabei den Großteil des Buches aus. Insgesamt eine durchaus empfehlenswerte Lektüre.


Struktur

Das Buch hat keine Strukturierungseinheiten oberhalb der Kapitelebene. Nichtsdestotrotz sind drei logische mehr oder minder unabhängige Teile identifizierbar.

Der erste Teil ist das erste Kapitel, das als hands-on Einführung zum Thema Refactoring verstanden werden kann. Die folgenden drei Kapitel (Prinzipien des Refactorings, Code-Smells: Schlechte Gerüche im Code und Tests erstellen) geben Antworten auf die Fragen: Was ist Refactoring, was ist dabei zu beachten und wann ist es einzusetzen.

Der letzte und bei Weitem umfangreichste Teil (über zwei Drittel des Buches) ist der Katalog, welcher Refactorings auflistet, beschreibt und beispielhaft erläutert.

Inhalt

Einleitung

Martin Fowlers erste Ausgabe des vorliegenden Buches, geschrieben zusammen mit Kent Beck, John Brant, William Opdyke und Don Roberts, war ein Erfolg. In der Einleitung der zweiten Auflage erfährt der Leser, was dazu geführt hat: dass zwar die „Essenz des Buches […] unverändert [sei]“ (S. 20), dessen hohes Alter aber eine Überarbeitung notwendig gemacht habe.

So sind die veranschaulichenden Beispiele nicht mehr in Java geschrieben, sondern in JavaScript, eine Sprache, die nach dem Dafürhalten des Autors von den meisten Entwicklern verdstanden werden könne (vgl. S. 22). Die letzten Kapitel der ersten Ausgabe (Big Refactorings, Refactoring, Reuse and Reality, Refactoring Tools und Putting It All Together) wurden nicht übernommen, was auch zu einer kürzeren Autorenliste geführt hat. Lediglich beim dritten Kapitel Code-Smells: Schlechte Gerüche im Code tritt Kent Beck als Mitautor auf.

Refactoring: Ein erstes Beispiel

Im ersten Kapitel veranschaulicht Martin Fowler anhand eines kurzen, aber aussagekräftigen Beispiels die Praxis des Refactorings. Dabei unterstreicht er wiederholt die Wichtigkeit kleiner Änderungen, die von den Vorgängen des Kompilierens, Testens und Eincheckens gefolgt sein sollten.

Prinzipien des Refactorings

Während das erste Kapitel vollkommen auf die praktische Ausübung der Tätigkeit des Refactorings ausgerichtet ist, geht das zweite auf weiterführende theoretische und praktische Hintergründe und Nebenbedingungen des Refactorings ein.

Refactoring wird als „[e]ine Änderung an der internen Struktur von Software, um sie verständlicher zu machen und Modifikationen zu erleichtern, ohne dass sich das sichtbare Verhalten verändert“ definiert (S. 79). Zusätzlich versteht Fowler „Refactoring“ als die Tätigkeit, welche zur Umstrukturierung führt (vgl. S. 79). Entwickler sind dabei einerseits mit dem Programmieren und andererseits mit dem Refactoring beschäftig: das sind „die beiden Hüte“ wie sie Kent Beck genannt hat.

Dass Refactoring nicht in sich begründet ist, sondern ganz pragmatischen Zielen dient, wird dem Leser des Buches relativ schnell klar. Fowler fasst vier Gründe für das Refactoring zusammen:

  • Verbesserung des Softwaredesigns
  • Verbesserung und Vereinfachung der Software, mit dem Ziel diese für Menschen verständlicher zu machen
  • Robusterer Code durch leichteres Aufspüren von Bugs
  • Und schnellerer Fortschritt beim Programmieren durch verständlicheres Design.

Die Frage nach dem geeigneten Zeitpunkt für Refactorings wird vielfältig beantwortet. Es gibt tatsächlich viele Momente, wann ein Refactoring Sinn machen kann: so z.B. kann der Code geändert werden, um ein geplantes Feature einfacher zu implementieren oder es wird planmäßig als Teil von Code-Reviews durchgeführt oder eben ganz spontan.

Die brisante Frage über den Umgang mit Vorgesetzten, die eine schlechte Meinung von Refactoring haben, beantwortet Fowler ganz klar (kursive Hervorhebung im Original): „Informieren Sie Ihren Chef nicht!“ (S. 89). Die Begründung ist so einfach, wie pragmatisch: als Profi sei man dafür zuständig seine Arbeit ordentlich und schnell zu erledigen, Refactoring würde eben dabei helfen (vgl. S. 89).

Im Unterkapitel 2.5 geht der Autor auf einige Herausforderungen, die beim Refactoring auftreten können, ein. So ist z.B. eine Kultur, in der jeder Entwickler nur für seinen Code zuständig ist, nicht einer Verbesserung desselben durch Refactoring zuträglich. Tests sind für risikoarme Refactorings eine Voraussetzung und Legacy Code ist im Allgemeinen eine Herausforderung. An dieser Stelle empfiehlt er Michael Feathers ebenfalls sehr erfolgreiches Buch Effektives Arbeiten mit Legacy Code.

Auf das potenzielle Problem der schlechteren Performance des Codes nach einem Refactoring geht Fowler gesondert in einem Unterkapitel ein. Seine Empfehlung ist es, das Thema Performance erst nach kompletter Durchführung der Refactorings und erst bei Bedarf in Angriff zu nehmen. Gute Compiler und moderne Hardware würden viele potenzielle Performance-Probleme erst gar nicht auftreten lassen.

Das zweite Kapitel wird mit einem kurzen geschichtlichen Überblick des Themas, mit einigen Tools zur automatisierten Durchführung von Refactorings und mit einer kurzen Liste weiterführender Literatur beendet.

Code-Smells: Schlechte Gerüche im Code

Im dritten Kapitel, eine Zusammenarbeit mit Kent Beck, werden sogenannte Code-Smells vorgestellt. Diese „Gerüche“ werden als ein guter Startpunkt für Refectorings vorgestellt. Die vierundzwanzig Code-Smells werden wegen ihrer großen Popularität hier nicht weiter beschrieben werden, lediglich einige wenige sollen zur Veranschaulichung benannt werden: Redundanter Code, Lange Funktion, Globale Daten, Obsession für elementare Datentypen, Spekulative Generalisierung und andere.

Tests erstellen

Im kurzen vierten Kapitel geht Fowler auf das Thema Testing ein. Tests werden als sehr wichtig für risikoarme Refactorings dargestellt.

Der Katalog

In der Einleitung schreibt der Autor, dass der Katalog als Nachschlagwerk gedacht sei und somit nicht in einem Zug gelesen werden müsse (vgl. S. 24). Ich schließe mich nur teilweise dieser Empfehlung an: um bestmöglich in der Lage zu sein die richtigen Stellen „nachzuschlagen,“ sollte zumindest ein grober Überblick vorhanden sein. Die Struktur der einzelnen Refactorings entspricht folgendem Format:

  • Name, gefolgt von einem sehr kurzen Beispiel, vom Autor „Skizze“ genannt (enthält nur Anfang- und Endzustand, keine Zwischenschritte)
  • Motivation
  • Vorgehen
  • Und ein ausführliches Beispiel.

Um sich nun einen Überblick zu verschaffen, empfehle ich das Durchlesen der Skizze und der Motivation.

Die vielen Refactorings sind in sieben Gruppen, die jeweils in einem eigenen Kapitel besprochen werden, zusammengefasst:

  • Kapitel 6: Eine erste Zusammenstellung von Refactorings
  • Kapitel 7: Kapselung
  • Kapitel 8: Verschiebungen
  • Kapitel 9: Daten organisieren
  • Kapitel 10: Bedingungen vereinfachen
  • Kapitel 11: Refactoring von APIs
  • Kapitel 12: Der Umgang mit Vererbung

Im Vergleich zur ersten Auflage sind neue Refactorings hinzugekommen, einige wurden entfernt und einige umbenannt. Der Autor betont jedoch, dass es sich dabei lediglich um eine Auswahl handle und die Zahl an möglichen Refactoring weitaus höher sei.

Anhang

Die drei Anhänge (A, B und C) beinhalten die Bibliografie, eine Auflistung der Refactorings (deutsche und englische Bezeichnung) und eine Auflistung der Code-Smells mit jeweils dazu passenden Refactorings.

Diskussion

„Refactoring hat die Denkweise über Softwarearchitektur nachhaltig verändert“ (S. 97) schreibt Fowler im zweiten Kapitel, und da liegt er nicht falsch. Das Wort Refactoring ist mittlerweile genauso in das Vokabular jedes Entwicklers eingegangen wie Design Patterns oder Unit-Testing. Und Fowlers Buch hat maßgeblich dazu beigetragen, dass es so kam. Da stellt sich fast die Frage, was noch zu solch einem Klassiker gesagt werden kann. Aber das Buch wurde neu aufgelegt und deswegen verdient es auch, neu besprochen zu werden.

Leicht nachvollziehbar, erklärt der Autor in der neuen Auflage seines erfolgreichen Buches, wie Code durch Refactoring verbessert werden kann und gibt handfeste Gründe, weswegen Refactoring kein unnötiger Mehraufwand darstellt, sondern langfristig sogar Zeit einsparen kann. Der angenehme Sprachstil macht die Lektüre kurzweilig und die Code-Beispiele sind vermutlich für alle oder zumindest für die allermeisten Entwickler, auch für die, welche JavaScript nicht unbedingt ihr daily Business nennen, gut verständlich.

An wen richtet sich das Buch? Fowlers Antwort ist: „[an] fortgeschrittene Programmierer – an Menschen, die mit dem Schreiben von Software ihren Lebensunterhalt verdienen“ (S. 23). Ich denke, genauso wie im Falle der eingangs genannten Design Patterns, dass jeder Entwickler mit dem Thema Refactoring vertraut sein muss und zumindest wissen sollte wo er oder sie im Bedarfsfall nach weiteren Informationen suchen kann. Programmierneulinge werden vielleicht die Wichtigkeit und Tragweite der Refactoring-Thematik nicht ganz einschätzen können, erfahrene Entwickler werden vielleicht etwas gelangweilt mit den Schultern zucken, Refactoring ist jedoch ein Thema, an dem letztendlich kein Entwickler vorbeikommt.

Somit ist das Buch auch heute noch genauso relevant, wie es im Jahre 1999, als die erste englische Auflage publiziert wurde, war.


Zu den Autoren

Martin Fowler

Martin Fowler ist einer der prominentesten Entwickler weltweit. Fowler ist Autor mehrerer erfolgreicher Bücher, Speaker und ist tätig als Berater bei ThoughtWorks, wo er den Rolle des Chief Scientist innehat.

Zusammen mit Kent Beck, Robert C. Martin, Ward Cunningham und anderen ist er einer der 17 initialen Unterzeichnern des Manifests für Agile Softwareentwicklung.

Er ist unter anderen Autor folgender Bücher:

  • Analysis Patterns: Reusable Object Models. Addison-Wesley. (1996)
  • Refactoring: Improving the Design of Existing Code. Addison-Wesley. (1999) (zusammen mit Kent Beck, John Brant, William Opdyke und Don Roberts)
  • Patterns of Enterprise Application Architecture. Addison-Wesley. (2002) (zusammen mit David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford)
  • Domain-Specific Languages. Addison-Wesley. (2010) (zusammen mit Rebecca Parsons)

Informationen über Martin Fowler im Katalog der Deutschen Nationalbibliothek.

Kent Beck

Kent Beck ist einer der prominentesten Entwickler weltweit. Er ist unter anderem Begründer der Entwicklungsmethodik Extreme Programming (XP) und Entwickler der SUnit-Bibliothek zum Schreiben von Unit-Tests in Smalltalk. SUnit wurde durch Beck in Zusammenarbeit mit Erich Gamma nach Java unter dem Namen JUnit portiert.

Kent Beck ist ebenfalls einer der 17 initialen Unterzeichner des Manifests für Agile Softwareentwicklung und der Begründer bzw. nach eigener Betrachtung „Wiederentdecker“ des Test Driven Development-Ansatzes (TDD), dessen starker Verfechter er ist.

In seiner langjährigen Karriere war er für diverse Unternehmen tätig, unter diesen für Apple Computer und Facebook. Aktuell ist er unter anderem als Entwickler bei Three Rivers Consulting, Inc. und als Leiter für Junit.org tätig.

Er sieht seine eigene Mission darin „Geeks“ zu verhelfen sich sicherer in der Welt zu fühlen.

Er ist unter anderen Autor folgender Bücher:

  • Smalltalk Best Practice Patterns. Prentice Hall. (1997)
  • Extreme Programming Explained: Embrace Change. Addison-Wesley. (1999)
  • Test-Driven Development by Example. Addison-Wesley. (2002)
  • JUnit Pocket Guide. O’Reilly. (2004)

Informationen über Kent Beck im Katalog der Deutschen Nationalbibliothek.


Folgende Bücher könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Als studierter Psychologe und Software Engineer war er knappe sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Mit der Gründung der Rezensionsplattform nososo hat er sich entschieden eigene Wege zu gehen. Petre ist als Rezensent und Verfasser von Artikeln für nososo tätig.

Schreibe einen Kommentar