Bad Code Smells. 20. Mai 2015

Transkript

1 Bad Code Smells 20. Mai 2015

2 Überblick Was sind Bad Code Smells? Welche Arten von Bad Code Smells gibt es? klasseninterne klassenübergreifende Welche Werkzeuge zur Analyse von Bad Code Smells gibt es? Taentzer Softwarequalität

3 Was sind Bad Code Smells? Anrüchige (verdächtige) Code-Stellen Hier lohnt es sich, genauer hinzuschauen. Sollten eventuell durch Refactoring-Maßnahmen restrukturiert werden. Kondensierung von Erfahrungswissen Syntaktische Prüfung von Programmcode hinsichtlich bestimmter Muster Analytische Qualitätssicherungsmaßnahme für bessere Wartbarkeit bessere Erweiterbarkeit geringere Fehleranfälligkeit Überblick über Bad Code Smells in [Fowler]. Taentzer Softwarequalität

4 Klasseninterne Bad Smells doppelter Code lange Methoden lange Parameterlisten viele Änderungen einer Klasse temporäre Felder sich wiederholende Switch-Anweisungen Kommentare Taentzer Softwarequalität

5 Doppelter Code einer der häufigsten Bad Code Smells gleicher oder sehr ähnlicher Code, der mehrfach auftritt Hauptgrund: Copy-and-Paste-Programmierung schnelle Wiederverwendung von Code Beispiele: derselbe Codeblock in zwei Methoden derselben Klasse oder in zwei Unterklassen einer gem. Oberklasse oder in zwei komplett verschiedenen Klassen Taentzer Softwarequalität

6 Beispiel: Doppelter Code void printinformation() { printtitle(); //print details System.out.println ("name: " + name); System.out.println ( address: " + getaddress()); } void printaddressbook() { for(int i = 1; i <= book.length; i++) { //print address System.out.println ("name: " + book[i].name); System.out.println ( address: " + book[i].getaddress()); } } Taentzer Softwarequalität

7 Lange Methoden Vermeidung von Spaghetti-Code Je länger eine Methode, desto fehleranfälliger Wiederverwendung von Codefragmenten wird nicht ermöglicht. Statt Kommentierung von Codeblöcken, besser den Block als Methode rausziehen Prinzipielles Vorgehen: Codeblöcke identifizieren nötige Parameter und temporäre Variablen identifizieren komplexe Bedingungen zerschlagen Taentzer Softwarequalität

8 Lange Methode Originalmethode mit vielen Codezeilen // Codeblöcke identifizieren, die in einzelne Methoden ausgelagert werden // // Taentzer Softwarequalität

9 Lange Parameterlisten Lange Parameterlisten erschweren das Verständnis von Methodenaufrufen. Sind Parameter besser als globale Variablen? Einsparen von Parametern: Verwendung von Objektanfragen Verwendung von Parameterobjekten Beispiel: Calendar insertappointment(start: Time, end: Time) showappointments(start: Time, end: Time) cancelappointments(start: Time, end: Time) Wann könnten lange Parameterlisten gewollt sein? Taentzer Softwarequalität

10 Viele Änderungen einer Klasse Verschiedene Änderungswünsche führen zu Änderungen derselben Klasse. Beispiel für verschiedene Änderungen einer Klasse: Änderung einer Datenzugriffsklasse, falls sich die Datenbank ändert Codeänderungen, wenn sich Geschäftsregeln ändern Einfügen neuer Aspekte (Z.B. wird ein Logging- Mechanismus eingeführt.) Beispiel: eine Klasse, die zu viele verschiedenartige Felder hat Person name: String birthday: Date position: PositionType phone: int fax : int street: String zip: int city: String Taentzer Softwarequalität

11 Temporäre Felder Felder einer Klasse beschreiben die Zustände ihrer Objekte. Manchmal sind Felder nur zeitweise gesetzt. Zur Vermeidung von langen Parameterlisten werden Felder erzeugt. Beispiel: PhoneBook searchresult: int searchnumber() 1 * Phone number: int Taentzer Softwarequalität

12 Kommentare und sich wiederholende Switch-Anweisungen Kommentare: Kommentare sind an sich nichts Schlechtes. Im Gegenteil: Sie sind gut! Manchmal weisen Kommentare auf schlechten Code hin. Kruder Code soll durch Kommentare verständlicher werden. Switch-Anweisungen: Häufig ähnliche Switch- Anweisungen an mehreren Stellen im Code Besser eine Switch- Anweisung in eine eigene Methode extrahieren Taentzer Softwarequalität

13 Beispiel: Sich wiederholende Switch-Anweisungen class Article { private int category; public static int getprize() { switch(category){ case `Shoes : case `Underwear : }} public static int getname() { switch(category){ case `Shoes : case `Underwear : }} Taentzer Softwarequalität

14 Klassenübergreifende Bad Smells große Klassen Änderungen in vielen verschiedenen Klassen aufgrund von einem Änderungswunsch Methoden, die zuviel auf andere zugreifen Datenhaufen faule Klassen Nachrichtenketten verweigertes Erbe auf Verdacht allgemein gehaltener Code Taentzer Softwarequalität

15 Große Klassen meist zu viele Felder Redundanzen innerhalb der Klasse vermeiden Turn five 100 line methods into five 10 line methods with another ten 2 line methods extracted from the original. Szenarien: Manche Felder lassen sich gut in neuen Objektklassen zusammenfassen. Bei zu viel Code: Methoden herausziehen, durch Verkürzung der Methoden redundanten Code finden Herausziehen von Schnittstellen kann aufzeigen, wie eine Klasse in mehrere Klassen zerlegt werden kann. Konvertierung von Konstanten in Aufzählungstypen Taentzer Softwarequalität

16 Beispiel: Große Klassen vorher Taentzer Softwarequalität

17 Beispiel: Große Klassen nachher Taentzer Softwarequalität

18 Änderung viele Klassen betreffend Ein Änderungswunsch, der viele Klassen betrifft. Änderungsstellen sind schwer zu finden, es kann schnell eine vergessen werden. Klassenstruktur semantisch nicht passend Manchmal ist die Änderung vieler Klassen bei einem Änderungswunsch auch gewollt. Wann? Copy-and-Paste- Programmierung: schnelle Wiederverwendung Wenn der Code anschließend stark modifiziert wird, ist Copyand-Paste adäquat. Boredom-Is-A-Smell: dieselben Einträge bei vielen Klassen Taentzer Softwarequalität

19 Methoden, die zuviel auf Daten anderer Klassen zugreifen Der Fokus einer Klasse sind ihre Daten. verdächtig: eine Methode, die mehr auf Daten anderer Klassen zugreift Eine Methode sollte zu der Klasse gehören, deren Daten sie überwiegend verwendet. class Room { Lecture[] lectures; } class Lecture { int id; boolean roomused(room r) { for(int i= 0; i < r.lectures.length; i++) { if (r.lectures[i].id == id) return(true); } return(false); } }... if (l.isinroom(r))... Taentzer Softwarequalität

20 Datenhaufen und faule Klassen Datenhaufen: Oft hängen mehrere Daten zusammen. Wenn Daten immer gemeinsam auftreten neue Datenklassen Welche Vor- und Nachteile bringen neue Datenklassen? Datenklassen müssen noch mit Funktionalität angereichert werden. Faule Klassen: Klassen mit zu wenig Funktionalität mögliche Gründe: zu ausgeprägte Klassenhierarchie reine Datenklassen Taentzer Softwarequalität

21 Beispiel 1: Bad Code Smells vorher Taentzer Softwarequalität

22 Beispiel 1: Bad Code Smells nachher Taentzer Softwarequalität

23 Beispiel 2: Bad Code Smells vorher Taentzer Softwarequalität

24 Beispiel 2: Bad Code Smells nachher Taentzer Softwarequalität

25 Beispiel 3: Bad Code Smells vorher Taentzer Softwarequalität

26 Beispiel 3: Bad Code Smells nachher Taentzer Softwarequalität

27 Nachrichtenketten Kaskaden von Methodenaufrufen sind verdächtig. Einkapselung geht häufig mit Delegation einher. Wenn eine Klasse die meisten seiner Methodenaufrufe an eine andere Klasse delegiert, kann sie eliminiert werden. Zwei Klassen, die zu stark miteinander kommunizieren, sind verdächtig. Beispiel: getperson(i).getaddress(). getstreet().gethousenumber(). print(); Street Person getaddress() Address getstreet() getcity() City Taentzer Softwarequalität

28 Verweigertes Erbe Subklassen, die zu wenige Methoden und Felder von ihren Elternklassen verwenden Schnittstellen sollten immer wiederverwendet werden. Methodenrümpfe müssen nicht wiederverwendet werden. Verdächtig: Eintrag ist nur für eine Schwesterklasse interessant. Bei Verdacht: Vererbung durch Delegation ersetzen Beispiele: Student List Person matrikelnr: int Dozent Stack Taentzer Softwarequalität

29 Auf Verdacht allgemein gehaltener Code Code für alle Eventualitäten abstrakte Klassen, die nicht viel Funktionalität enthalten Parameter, die nicht gebraucht werden Code, der nur in Testklassen verwendet wird Beispiele: Methodenname reicht nicht, um den Inhalt zu verstehen Eine Methode wird immer mit dem gleichen Wert aufgerufen. Abstrakte Klasse mit nur einer Unterklasse Template, das mit nur einem Argumenttyp sinnvoll ist Taentzer Softwarequalität

30 Code Smell Metriken Umfangsmetriken Methoden mit mehr als 20 Code-Zeilen, mehr als 3 Parameter oder mehr als 2 Ebenen tief Klassen mit mehr als 10 öffentlichen Methoden und einigen wenigen privaten Methoden Namensgebung schlechte Namen für Klassen, Methoden oder Variablen doppelte Code-Fragmente nicht durch Tests abgedeckte Code-Fragmente Taentzer Softwarequalität

31 Werkzeuge Werkzeuge, mit denen man Bad Code Smells entdecken kann: CodePro AnalytiX Eclipse Plugin Metrics Eclipse Plugin Checkstyle Eclipse Plugin PMD... Da Code Smells projektspezifisch eingestellt werden sollten, erlauben diese Werkzeuge auch die Spezifikation der aktiven Smells. Taentzer Softwarequalität

32 Empirische Studien zu Bad Code Smells Klassen mit Bad Smells werden öfter geändert als andere und können die Weiterentwicklung behindern. [KPG09] Verbesserungen am Sourcecode sollten auf der Basis von Code Smells und persönlichen Einschätzungen vorgenommen werden. [ML06] Gottklassen sind Klassen, die viel Intelligenz des Systems enthalten, eine hohe Komplexität haben und viele Daten anderer Klassen nutzen. Gottklassen werden öfter als andere geändert. Werden sie aber bzgl. ihrer Größe normalisiert, tritt eher ein gegenteiliger Effekt auf. [OCS10] Ein Smell ist noch kein Problem, aber mehrere. [AKG+11] Automatische Smell-Erkennung hilft beim Code-Review. [SZS+10] Taentzer Softwarequalität

33 Zusammenfassung Qualitätssicherungsmaßnahme für Besser Lesbarkeit des Codes bessere Wartbarkeit geringere Fehleranfälligkeit Ziel der Analyse durch Bad Code Smell: Vermeidung von Coderedundanzen: Once and only once bessere Strukturierung des Codes Auffinden von ungenutzten Codeanteilen Zwei Arten des Code Review: pragmatisch: Code Smells werden von Fall zu Fall angesehen und eventuell eliminiert. puristisch: Alle Code Smells werden eliminiert. Werkzeuge können automatisch verdächtige Code- Stellen finden. Taentzer Softwarequalität

34 Literatur [Fowler] M. Fowler: Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999 [KPG09] Khomh, Foutse, Massimiliano Di Penta, and Y. Gueheneuc. "An exploratory study of the impact of code smells on software changeproneness." Reverse Engineering, WCRE'09. 16th Working Conference on. IEEE, [ML06] Mäntylä, Mika V., and Casper Lassenius. "Subjective evaluation of software evolvability using code smells: An empirical study." Empirical Software Engineering 11.3 (2006): [OCS10] Olbrich, Steffen M., Daniela S. Cruzes, and Dag IK Sjoberg. "Are all code smells harmful? A study of God Classes and Brain Classes in the evolution of three open source systems." Software Maintenance (ICSM), 2010 IEEE Int. Conference on. IEEE, CameraReady.pdf Taentzer Softwarequalität

35 Literatur [AKG+11] Abbes, Marwen, et al. "An empirical study of the impact of two antipatterns, blob and spaghetti code, on program comprehension." /Software Maintenance and Reengineering (CSMR), th European Conference on/. IEEE, p=rep1&type=pdf [SZS+10] Schumacher, Jan, et al. "Building empirical support for automated code smell detection." /Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement/. ACM, young/cs-classes/oldfiles/csse575/resources/a8-schumacher.pdf Interessante Links: Code Smell Katalog: The Catalog of Refactoring - Code Smell Taentzer Softwarequalität