Allgemeine Beschreibung
Ein Buch mit 353 Seiten, das man kaum als vollwertiges Buch bezeichnen kann und das eher eine Ergänzung zum entsprechenden Refactoring-Kurs darstellt. Der Lesbarkeitsgrad ist einfach. Es gibt nicht viel Programmcode, alle Beispiele sind eher als Abstraktionen in Form von Flussdiagrammen und Diagrammen aufgebaut. Im ersten Teil des Buches gibt es auch Bilder, die thematisch gut ausgewählt sind und den Inhalt ergänzen.
Kurzer Überblick
Der erste Teil des Buches widmet sich den sogenannten "Code-Gerüchen", wie der Autor es nennt. Im Grunde sind es Anzeichen dafür, dass es Zeit ist, bestimmten Code zu refaktorieren. Die Anzeichen sind in verschiedene Gruppen unterteilt, zum Beispiel die erste Gruppe "Aufblähungen" und enthält Beispiele wie große Methoden, große Klassen, lange Parameterlisten und Ähnliches. Es gibt auch viele andere Gruppen, wie zum Beispiel "Verletzung des OOP-Designs", "Arbeit mit Vererbung", "Temporäre Variablen" und vieles mehr.
Der zweite Teil widmet sich etwas praktischeren Lösungen für die im ersten Teil beschriebenen Probleme. Zum Beispiel, welche Ansätze man anwenden sollte, wenn Klassen oder Methoden groß sind, wie man sie aufteilt, wie man Code extrahiert und alle alten Code-Vorkommen durch neuen ersetzt. Hier sind übrigens alle Praktiken ebenfalls in verschiedene Gruppen unterteilt, von denen sich eine beachtliche Menge angesammelt hat.
Meinung
Zum Zeitpunkt der Lektüre des Buches hatte ich bereits über 10 Jahre Berufserfahrung als Programmierer, ohne die vielen Jahre in der Schule und der Uni zu zählen, also muss ich ehrlich sagen, dass ich mich kaum erinnern kann, auf neue Ratschläge gestoßen zu sein, die für mich neu gewesen wären. Genau deshalb habe ich für dieses Buch keine Zusammenfassung erstellt. Dennoch wäre es für angehende Programmierer sinnvoll, sich mit dem Buch zu befassen, zumal es sich sehr schnell lesen lässt.
Das gesamte Buch handelt hauptsächlich von OOP, und über funktionalen Programmierung gibt es nicht so viele Informationen. Im Grunde genommen ist weder gut noch schlecht, sondern nur Feststellung des Sachverhalts. Natürlich gab es Beispiele, mit denen ich kaum einverstanden bin, aber das ist alles reine Geschmackssache. Darüber hinaus können sich Schreibstil und Designmuster in verschiedenen Programmiersprachen leicht unterscheiden, sodass der Autor versucht, eine mittelmäßig universelle Position zu wählen und sich daran zu halten. Oft trifft man auf Beispiele, bei denen wir in einer Art von Refactoring zuerst eine bestimmte Maßnahme durchführen (wir extrahieren eine separate Klasse, wo es logisch erforderlich ist), während im nächsten Beispiel im Gegenteil Klassen zusammengefügt und die Hierarchie vereinfacht wird. So betont der Autor, dass jede Situation einzigartig ist und bestimmte Muster je nach Situation und nicht schematisch angewendet werden müssen.
