Um Code Smells und ihre Behebung mittels Refactorings geht es in
der einhundertsiebenundvierzigsten Episode des
Anwendungsentwickler-Podcasts. Inhalt Was ist ein Code Smell?
Smells sind Indikatoren für Code, der überarbeitungswürdig ist. Man
erkennt sie anhand verschiedener Muster (z.B. lange Methoden). Die
Smells können mit Refactorings überarbeitet und (hoffentlich)
eliminiert werden. Nicht alle Smells sind immer schlecht. Sie
dienen nur als Anhaltspunkt, noch einmal über den Code
nachzudenken. Woher kommt der Name Code Smell? Kent Becks Oma wird
das Zitat "If it stinks, change it." zugesprochen, das sich auf das
Wechseln von Windeln bei Babys bezieht. Kent Beck hat diese Idee
auf Code übertragen: Wenn der Code seltsam "riecht", sollte man ihn
anpassen. Wobei helfen uns Code Smells? Mit Code Smells können wir
Stellen im Code aufdecken, die problematisch sind, und diese
überarbeiten. Dadurch wird der gesamte Code insgesamt "besser". Die
benannten Smells helfen uns durch eine gemeinsame Sprache bei der
Diskussion mit anderen Entwicklern (ähnlich wie Design Pattern).
Was können wir gegen Code Smells tun? Das Mittel gegen Code Smells
sind die Refactorings. Im Buch von Martin Fowler* gibt es eine
übersichtliche Tabelle, welche Refactorings gegen welche Smells
helfen können. Sind Code Smells immer böse? Code Smells sind nur
ein Anhaltspunkt für Optimierungen. Der Entwickler muss selbst
entscheiden, ob der Smell schlecht ist. Einige Code Smells hängen
zusammen und das Auflösen des einen (z.B. Introduce Parameter
Object) führt zur Einführung eines anderen (z.B. Data Class).
Welche Code Smells gibt es? Duplicate Code Doppelter Code führt bei
Änderungen schnell zu Fehlern, weil zu ändernde Stellen übersehen
werden. Refactorings: Extract Method, Pull Up Method Comments
Kommentare können helfen, den Code zu verstehen, aber häufig sind
sie überflüssig und können durch sprechendere Bezeichner komplett
eliminiert werden. Refactorings: Extract Method, Rename Method Long
Method Lange Methoden sind schwieriger zu verstehen, zu testen und
anzupassen. Refactorings: Extract Method Large Class Zu große
Klassen machen häufig mehr als sie sollen und verletzen das Single
Responsibility Principle. Das macht sie u.a. schwer testbar.
Refactorings: Extract Class, Extract Subclass Long Parameter List
Viele Parameter bei Methoden deuten darauf hin, dass diese zu viele
Aufgaben übernehmen. Sie machen die Methoden schwer testbar und
schwer verständlich. Außerdem müssen die Parameterlisten
tendenziell oft angepasst werden. Refactorings: Replace Parameter
with Method, Introduce Parameter Object Feature Envy Wenn Methoden
oder Klassen sich viele Informationen "besorgen" müssen, bevor sie
ihren Job machen können, ist das ein Zeichen dafür, dass die
Komponenten besser an einer anderen Stelle aufgehoben wären.
Refactorings: Move Method Data Clumps Wenn verschiedene Daten immer
zusammen herumgereicht werden (z.B. Startdatum und Endedatum), ist
das ein Zeichen für eine fehlende Abstraktion (z.B. Zeitraum).
Refactorings: Introduce Parameter Object, Extract Class Primitive
Obsession Die Scheu vor eigenen kleinen Klassen führt oft dazu,
dass doppelter Code entsteht und eine gute Kapselung verhindert
wird. Refactorings: Replace Data Value with Object, Extract Class,
Introduce Parameter Object Switch Statements: Gleiche
Fallunterscheidungen werden häufig an mehreren Stellen benötigt und
führen zu doppeltem Code, der mit Polymorphie verhindert werden
könnte. Divergent Change: Einzelne Klassen müssen aufgrund von
verschiedenen Änderungen angepasst werden. Shotgut Surgery:
Aufgrund einer einzelnen Änderung müssen verschiedene Klassen
angepasst werden. Parallel Inheritance Hierarchies: Sonderform von
Shotgun Surgery, die das parallele Anlegen von Subklassen in
verschiedenen Hierarchien erfordert. Lazy Class: Zu kleine Klassen,
die keinen erkennbaren Mehrwert haben, sollten abgelöst werden.
Speculative Generality: Anstatt alle möglichen zukünftigen
Entwicklungen zu antizipieren, sollte besser das Prinzip You Ain't
Gonna Need It befolgt werden. Temporary Field: Instanzvariablen
sollten nicht nur während der Laufzeit einzelner Methoden verwendet
werden. Message Chains: Objekte, die Objekte aufrufen, die wieder
Objekte aufrufen, wissen zu viel über die fremde Implementierung
und sind damit stark gekoppelt. Das verletzt das Law of Demeter.
Middle Man: Zu viel Delegierung ist auch nicht gut. Inappropriate
Intimacy: Klassen sollten nicht zu viele Details anderer Klassen
kennen. Alternative Classes with Different Interfaces: Gleiche
Dinge sollten auch gleich benannt sein. Incomplete Library Class:
Wenn Librarys nicht alles tun, was wir brauchen, sollten wir sie
ergänzen, anstatt alles neu zu entwickeln. Data Class: Die guten
alten POJOs oder Java Beans. Sie verhindern häufig saubere
Kapselung und haben bei fehlender Geschäftslogik evtl. gar keine
Daseinsberechtigung. Refused Bequest: Wenn Subklassen Teile ihres
Vermächtnisses (geerbte Member) nicht nutzen wollen oder können,
ist vielleicht die Hierarchie falsch gewählt. Literaturempfehlungen
Eine sehr schöne Liste möglicher Code Smells und ihrer Auswirkungen
gibt es im Klassiker Refactoring von Martin Fowler*. * Links
Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Code
Smells Catalog of Refactorings Refactoring and Design Patterns
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.