Code Smell

Aus MimiPedia
Version vom 28. November 2024, 11:02 Uhr von Ullrich (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „Category:IT Die erste Erwähnung des Begriffs "code smell" findet sich in Martin Fowlers Buch "Refactoring". Er verwendet ihn dort als es darum geht die Code-Stellen zu identifizieren an denen Refactoring erforderlich ist. Fowler bleibt dabei ausgesprochen vage, aber die Andeutung auf verunreinigte Baby-Windeln erzeugt den starken Eindruck, daß es sich hier um ausgesprochen unangenehme Gerüche handeln muß... Ein Code Smell ist eine Stelle im Code…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Die erste Erwähnung des Begriffs "code smell" findet sich in Martin Fowlers Buch "Refactoring". Er verwendet ihn dort als es darum geht die Code-Stellen zu identifizieren an denen Refactoring erforderlich ist. Fowler bleibt dabei ausgesprochen vage, aber die Andeutung auf verunreinigte Baby-Windeln erzeugt den starken Eindruck, daß es sich hier um ausgesprochen unangenehme Gerüche handeln muß...

Ein Code Smell ist eine Stelle im Code mit bestimmten Eigenschaften, an denen sie zu erkennen ist. Diese Eigenschaften bilden den bisweilen charakteristischen Geruch. Eine Methode mit einer langen Parameterliste ist ein Beispiel dafür, mit jedem weiteren Parameter wird der Geruch intensiver.

Viele Code Smells haben eine Ursache. Eine lange Parameterliste zum Beispiel kann das Ergebnis sukzessiver Verallgemeinerung sein. Die ursprüngliche Methode hatte vielleicht nur zwei Parameter, aber mit jeder Anpassung an die geänderten Anforderungen kam ein neuer Parameter hinzu. Nicht jeder Smell hat eine klare Ursache, für manche Smells gibt es mehrere mögliche Ursachen. In aller Regel ist es sinnvoll die Ursache zu ergründen, denn unterschiedliche Ursachen können unterschiedliche Refactoring-Maßnahmen nahelegen. Hier endet ein Zipfel der Analogie, denn Baby-Kacke beseitigt man normalerweise immer auf die gleiche Weise...

Nicht alle Gerüche sind per se unangenehm. Fowler beschreibt zum Beispiel den Geruch von Kommentaren als angenehm – nachgerade verführerisch angenehm, denn fehlerhafte Kommentaren können Probleme – und die damit verbundenen Gerüche – verdecken.

Ich strecke die Analogie gerne in eine andere Richtung: Verschiedene Entwickler reagieren auf verschiedene Gerüche unterschiedlich. Dem einen wird bei einer 10-Zeilen-Methode übel, der andere fühlt sich vom 100-Zeilen-Geruch noch nicht belästigt. Und wieder scheinen den Duft von Methoden um so angenehmer zu emfinden, je länger sie wird.

Es ist Aufgabe des Teams eine Umgebung zu schaffen die einen vernünftigen Kompromiß bringt. Es wäre falsch, ganz auf die Beseitigung von Code-Smells zu verzichten. Ebenso falsch aber wäre es, die Beseitigung bestimmter Smells zu erzwingen –- um bei der Analogie zu bleiben: der Geruch von Desinfektionsmittel kann durchaus unangenehm sein.

Wie im wirklichen Leben, können Gerüche auf tödliche Gefahren hinweisen -– der Geruch von Bittermandel ist nicht unbedingt unangenehm, eine Zyanid-Vergiftung ist es aber auf jeden Fall... Doch nicht hinter jedem Geruch steckt ein verrotteter Fäulnisherd, der die Anwendung in eine einsturzgefährdete Todesfalle verwandelt. Manchmal handelt es sich lediglich um einen ungewohnten Eigengeruch, an dessen Aroma man sich erst gewöhnen muß.

Nachdem wir nun –- dem Duft der Analogie -– folgend um das eigentliche Thema herummäandert sind, bringen wir die Sache mal auf den Punkt:

  • Ein Code Smell ist der Hinweis auf eine Code-Stelle, die Beachtung verdient
  • Ein Code-Smell ist nicht per se schlecht
  • Ein Code Smell kann der Hinweis auf eine Schwachstelle sein, die zu ernsthaften Problemen führen kann
  • Code-Smells müssen in der Regel mit Rücksicht auf die Ursache behandelt werden

Nachdem wir nun eine Vorsetllung davon haben was einen Code Smell ausmacht, können wir uns nun den konkreten Beispielen befassen...

"Beliebte" Code Smells...

  • Shot Gun Surgery (Martin Fowler)
  • Speculative Generalization (Martin Fowler)
  • Zu viele Zeilen in der Methoden oder Klasse
  • Zu viele (mehr als drei) formale Parameter in der Methoden-Signatur
  • Ungenutzte Felder, Parameter, Methoden, Code etc.
  • Explizites type casting
  • Unangemessener Gebrauch von null
  • Auto-unboxing wegen unnötiger Verwendung von Wrapper-Klassen um int, long, etc.


Nachgedanke

Worte wie "eigentlich" und "wirklich" sind code smells der natürlichen Sprache.
Sie riechen nach "Ideologie".
Sie riechen nach "mir sind die rational-logischen Argumente ausgegangen"