Welcher Entwickler kennt das nicht: Anfangs war der Code so einiger maßen sauber, aber dann kam ein Fix hier, ein schnelles umsetztendes Feature da und kaum hat man sich versehen hat man technische Schulden aufgenommen.

Und wie die meisten ahnen, in aller Regel kann man nicht Großbank spielen und darauf hoffen, dass man den Status „To big to fail“ hat, sondern muss seine Schulden bezahlen. Aber wie sieht man, wo genau die Schulden sind? Erschwerend kommt hinzu: hin und wieder ist man sich gar nicht bewusst, dass an der einen oder anderen Stelle Schulden existieren.

Hier helfen die Code Smells weiter. Sie sind keine Bugs, sie hindern unsere Software nicht daran korrekt zu funktionieren. Aber sie geben Hinweise, wo Designschwachstellen zu finden sind, die zu langsamerer Entwicklung in der Zukunft und einem erhöhtem Bugrisiko führen können. Zum ersten Mal beschrieb sie Kent Beck im WardsWiki Ende der 90er. Richtig populär allerdings wurden sie mit Martin Fowlers Buch Refactoring: Improving the Design of Existing Code ¹.

Einen guten Überblick über alle Smells liefert diese Seite der beiden Autoren Kent Beck und Martin Fowler:
http://sourcemaking.com/refactoring/bad-smells-in-code

Wem das zuviel Text ist, der kann auch einfach durch die Folien meines Talks über Code Smells blättern, diese fassen alles Wichtige kurz und hoffentlich prägnant zusammen. Zu finden im Bereich Talks.

Tools wie FindBugs, PMD oder Checkstyle unterstützen beim Auffinden der meisten Smells, sie ersetzen jedoch nicht den aufmerksamen und allzeit kritischen Entwickler. Daher: immer fleißig schnüffeln und wenns riecht nicht einfach die Nase zuhalten (aka. Kommentar über den miefenden Kot schreiben), sondern aufräumen und sauber machen; und sich das nächste Mal darüber freuen, dass es eine Tretmine weniger gibt.