Code Smells und Refactorings – Anwendungsentwickler-Podcast #147

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