Refactoring - Wie Sie das Design vorhandener Software verbessern

von Martin Fowler
Deutsche Ausgabe, 440 Seiten
Addison-Wesley, München 2000
ISBN 3-8273-1630-8

Meine Wertung: 4.5 von 5 Punkten
Mein Amazon-Rating: 4 Sterne (BlueBallon Kurzbewertung auf Amazon.de)


Was unterscheidet guten von schlechtem Code?
Wie erkennt man schlechten Code?
Und - was meist noch wichtiger ist - wie beseitigt man ihn am besten?
Diese Fragen - auf die bei nahezu jedem Programmierprojekt stößt - sind die zentralen Punkte in Martin Fowler Standardwerk "Refactoring".

Es ist ein typisches "Best Practices" - Buch und er beschreibt darin ausführlich und mit viele Beispielen (durchgehend in Java) belegt, wie man schlechte Programmstellen "riechen" kann (er spricht hier von "Code Smells"), was an diesen Stellen eigentlich schlecht ist (zb welche Probleme verursachen überlange Routinen/Methoden?) und liefert für jeden der vorgestellten Problemfälle Schritt-für-Schritt-Rezepte, wie man den Zustand verbessert. Viele der Problemstellungen und -lösungen sind objektorientiert (Veränderungen der Klassenhierarchie, Fabrikmethoden, Klassenextraktion etc), aber viele andere lassen sich auch auf ausschließlich prozeduale Sprachen wie C oder gar Fortran anwenden (zb Vereinfachungen bedingter Ausdrücke, duplizierter Code, lange Routinen etc).
Viel Wert wird auch die Feststellung gelegt, wie wichtig UnitTests als Sicherheitsnetz für die eigentlichen Refactoringvorgänge sind. Konkret vorgestellt wird hierfür das JUnit-Framework, das Grundprinzip läßt sich aber natürlich (mehr oder weniger) auf jede beliebige Programmiersprache bzw Programmierumgebung anwenden.
Erwähnenswert ist vielleicht noch, daß Fowler ja bekanntermaßen ein Verfechter der "Agilen Methoden" ist (er ist ja auch einer der Verfasser des "Agilen Manifests", ein guter Bekannter von Kent Beck sowie der Autor zahlreicher Artikel wie zb Continuous Integration, sodaß es nicht verwunderlich ist, daß praktisch alle in diesem Buch beschrieben Vorgangsweisen sich sehr gut mit den typischen agilen Szenarien in Einklang bringen lassen. Insbesondere betrifft dies das Zerlegen der Aufgaben in kleine Arbeitsschritte, die sich möglichst schnell mit möglichst wenig Risiko umsetzen lassen - und dies ist ja auch für Projekte günstig, die nicht mit einem agilen Prozess arbeiten.

Kurz gesagt, das Buch ist genial, und jeder, der sich halbwegs ernsthaft mit professioneller Programmierung beschäftigt, sollte ein Exemplar davon zumindest in Griffweite haben. Von daher kriegt das Buche eigentlich 5 Punkte mit Rufzeichen, warum also nur 4.5 Punkte bzw 4 Amazon-Sterne?

Weil die Übersetzung ein echter Graus ist!
Addison-Wesley sollte sich hinsichtlich der Auswahl der Übersetzer ein Beispiel an O'Reilly nehmen und doch möglichst Leute nehemn, die etwas mehr vom Fach verstehen (IMHO wird nicht umsonst bei jedem O'Reilly Buch der Übersetzer besonders hervorgehoben und auch sein fachlicher Background beschrieben!) Es ist zwar nicht so, daß dass Buch durch die Übersetzung unverständlich wird, aber ich hab zB schon eine Zeitlang gebraucht zu begreifen, daß mit der Phrase "wandeln Sie um" einfach nur "compilieren" gemeint war.

Aber abgesehen davon - ein Pflichtwerk.