Refactoring ist ein ausgezeichnete Technik, um Code geordnet zu verändern, zu vereinfachen oder architektonisch umzuarbeiten. Es stellt sich jedoch die Frage, wie man erkennt, ob und welche Refactorings nötig sind, und wie weit man bei der Umarbeitung der betroffenen Codeteile gehen soll. Kurz: Wann fangen wir mit dem Refactoring an und wann hören damit auf?
Die kurze Antwort auf diese Frage lautet: So früh wie möglich. D.h. wir sollten mit dem Refactoring beginnen, wenn wir feststellen, dass mit unserem Detailentwurf (dem Programmcode) etwas nicht stimmt. Doch wie erkennen wir, dass ein Refactoring nötig ist?
Martin Fowler beschreibt in seinem Buch Refactoring zusammen mit Kent Beck eine Reihe von sogenannten Code Smells. Diese Code Smells helfen uns, schlechten Code zu entdecken, so dass wir ihn umarbeiten können.
Nachfolgend eine Liste der übelsten Gerüche, denen wir immer wieder begegnen:
- Duplicate Code (Codeduplizierung) - Die Nummer 1 in der Stinkparade! Die gleiche Codestruktur an mehreren Stellen oder der gleiche Ausdruck in mehreren Methoden sind wohl die häufigste Variante dieses Code Smell.
- Long Method (lange Methode) - Kurze, überschaubare Methoden haben in einem System die besten Überlebenschancen. Lange Methoden sind fehlerträchtig und schwierig zu warten. Die lange Methode von heute ist der Poltergeist von morgen!
- Large Class (grosse Klasse) - Bei grossen Klassen liegt die Vermutung nahe, dass sie zu viel tun und mehr als eine Schlüsselabstraktion einfangen. Die Grösse bezieht sich sowohl auf die Grösse der öffentlichen Schnittstelle als auch auf deren Umsetzung (Implementierung) in der Klasse. Grosse Schnittstellen mit vielen Methoden machen es dem Verwender unnötig schwer, die Klasse semantisch korrekt zu verwenden.
- Long Parameter List (lange Parameterliste) - Wenn eine Methode zu viele Argumente benötigt, wird ihre Verwendung unnötig kompliziert. OOP fördert den Gebrauch kurzer Parameterlisten, denn Objekte haben ihr eigenes Gedächtnis. Daher müssen wir einer Methode nur die Information übergeben, die das Objekt noch nicht besitzt.
- Divergent Change (Divergierender Code) - Dieses Problem tritt auf, wenn eine Klasse aus verschiedenen Gründen auf verschiedene Art und Weise geändert wird. Solche Klassen bilden in der Regel mehr als eine Schlüsselabstraktion ab.
- Shotgun Surgery (Schusswaffen Chirurgie) - Das Gegenteil von Divergent Change: Eine Änderung führt zu einerVielzahl von kleinen Änderungen in einer Vielzahl von Klassen.
- Feature Envy (Merkmalsneid) - Die häufigste Form dieses Smells: Datenneid; eine Klasse greift auf die Eigenschaften einer anderen zu, um dann z.B. eine Berechnung durchzuführen. Die einfache Regel: Put together what changes together.
- Data Clumps (Datenklumpen) - Datengruppen, die immer wieder zusammen auftauchen, sollten als Klasse abgebildet werden.
- Primitive Obsession (Bessesen von primitiven Typen) - Auch kleine Klassen sind wertvoll.
- Switch Statements (Switch Anweisungen) - Gut entworfene OO-Programme kommen praktisch ohne Switch- bzw. Case-Anweisungen aus. Fallunterscheidung auf dem Typ eines Objekt ist i.d.R. ein Fehler und kann durch Polymorphismus ersetzt werden.
- Message Chains (Methodenketten) - Dieser Smell tritt auf, wenn Das Gesetz von Demeter verletzt wird.
- Comments (Kommentare) - Kommentare sind kein eigentlicher Code Smell sondern vielmehr der Deostick des Programmieres, um schlechte Gerüche zu verdecken.
Lesen Sie hierzu auch:
Refactoring,
Zerbrochene Fenster und
Regelmässiges Testen.
If it stinks, change it!