Codequalität: Code-Metrik Version 0.1

Transkript

1 Codequalität: Code-Metrik Version 0.1 Sicherung und Verbesserung der Codequalität mit Hilfe von Code-Metrik Tools Team Code Orange 1

2 Inhalt Einleitung Tools: - Checkstyle - JavaNCSS - Findbugs - JDepend - Cobertura (Integration in Buildprozess) Team Code Orange 2

3 Einleitung Grundmotivation Regelmäßige Überwachung und Verbesserung der Codequalität ist essenziell für das technische und geschäftliche Überleben von Softwaresystemen Gerade in Zeiten der fortschreitenden Softwarekrise stellt Codequalität eine fundamentale Säule in der Softwareentwicklung dar Team Code Orange 3

4 Einleitung Grundmotivation Umfang und Ausprägung moderner Softwareprojekte erfordern moderne Lösungen zur Sicherung von Qualität des Codes und zur Überwachung des Codes (Codereviews) In der Praxis wird die sogenannte Quelltextrezension oftmals nur von wenigen bzw. einer Person durchgeführt (Softwarearchitekt) Team Code Orange 4

5 Einleitung Grundmotivation Der Softwarearchitekt kann unmöglich jede Codezeile manuell bezüglich Codequalität prüfen Softwareprojekte, Systeme, Teams und Unternehmen sind oft zu unterschiedlich für einheitlichen Standard bezüglich Codequalität Team Code Orange 5

6 Einleitung Einschub: Konservative Ansätze Regelmäßige Codereviews Eigene Erfahrung Einhaltung von Codeschablonen bzw. softwaretechnischen Verhaltensmustern Lösen jedoch oft nur eine kleine Untermenge von Problemen bezüglich Überwachung der Codequalität Team Code Orange 6

7 Einleitung Grundmotivation Problemlösungsansatz: Entwicklung/Einsatz von Vorgehensweisen zur Abbildung von Softwareeigenschaften in einem Zahlenwert (Maßzahl) Softwaremetrik (Codemetrik) Team Code Orange 7

8 Einleitung Codemetrik(Nutzung) Einsatz(Beurteilung) der Codemetrik erstreckt sich über mehrere Bereiche: Entwicklungsphasen Phasenergebnisse Technologien Ziel der Metriken Fehlerprognose und Aufwandsabschätzung Unterscheidung zwischen vorlaufend, mitlaufend und retroperspektiv Team Code Orange 8

9 Einleitung Codemetrik(Beschränkung) Metriken sollten überschaubar bleiben (eindimensional): Sicht des Managements Kosten, Produktivität, Risiken, Validierung Sicht des Entwicklers Lesbarkeit, Effizienz, Effektivität, Tests, Restfehler Sicht des Kunden Abschätzungen(Budget), Qualität, Wartbarkeit, Erweiterbarkeit Team Code Orange 9

10 Einleitung Codemetrik(Klassifikation) Verschiedene Metriken(Entwurfsmetrik, Kommunikationsmetrik usw.) werden speziellen Klassen zugeordnet: Prozess-Metrik Ressourcenaufwand, Fehler, Kommunikationsaufwand Produkt-Metrik Umfang, Komplexität, Lesbarkeit, Entwurfsqualität, Produktqualität Komplexitätsmetrik Softwaregröße, Fertigstellungsgrad Team Code Orange 10

11 Einleitung Codemetrik(Gütekriterien) Gütemerkmale werden in der Regel an der Erfüllung der Kundenanforderung gemessen Gütekriterien für den Kunden: Objektivität (keine subjektive Einflüsse des Messenden) Zuverlässigkeit (bei Wiederholung gleiche Ergebnisse) Normierung (Messergebnisskala und Vergleichbarkeitsskala) Team Code Orange 11

12 Einleitung Codemetrik(Gütekriterien) Gütekriterien für den Kunden(Fortsetzung): Vergleichbarkeit (Maß mit anderen Maßen in Relation setzbar) Nützlichkeit (messbare Erfüllung praktischer Bedürfnisse) Validität (von messbaren Größen auf andere Kenngrößen zu schließen (schwierig)) Team Code Orange 12

13 Einleitung Zusammenfassung Für den Menschen (Softwarearchitekt) ist es schwer manuell für eine entsprechende allgemeine Codequalität zu sorgen Lösung: Einsatz einer einheitlichen und allgemein anerkannten Metrik (Codemetrik) Im Folgenden werden Tools vorgestellt, welche zum größten Teil solche Codemetriken erstellen und realisieren Team Code Orange 13

14 Inhalt von Checkstyle Zitat Sinn und Zweck eines Coding Standards Fälle für die Coding Standards Sinn machen Definierte Punkte bei Checkstyle Einfaches Beispiel für schlecht lesbaren Code Beispiel für schlecht lesbaren Code Tipps Checkstyles als Eclipse-Plugin Team Code Orange 1

15 Zitat* von Martin Fowler Any fool can write code that a computer can understand. Good programmers write code that humans can understand *("Refactoring - Improving the design of existing code", Seite 15) Team Code Orange 2

16 Sinn und Zweck eines Coding Standards Ist das Erleichtern von Arbeiten am Code mit mehreren Leuten durch einheitliche Codestruktur innerhalb eines Entwicklungsteams Team Code Orange 3

17 Fälle für die Coding Standards Sinn machen Kommunikation Urlaubsvertretung funktionierender Code Übersichtlicher Code Module und Modultests Wiederverwendbarkeit des Codes Einfache Wartung des Codes Code, der leicht zu erweitern ist Team Code Orange 4

18 Definierte Punkte bei Checkstyle Einrückung Namenskonventionen Kommentare Begrenzung der Zeilenlänge Anzahl von Unterklassen Komplexität der Dateistruktur (Packages) Team Code Orange 5

19 Einfaches Beispiel für schlecht lesbaren Code Ein eingegebener Wert soll von einer temporären Variable einer speziell für Usereingaben definierte Variable zugewiesen werden Schlecht a = b; Gut inputuser = tempinput; Team Code Orange 6

20 Beispiel für schlecht lesbaren Code 48 through the loop, sortboundary is increased, and the element at the position of the 49 new sortboundary probably isn't in its sorted place in the array, so it's inserted 50 into the proper place somewhere between firstelement and sortboundary. */ for ( int 51 sortboundary = firstelement+1; sortboundary <= lastelement; sortboundary++ ) { int 52 insertval = data[ sortboundary ]; int insertpos = sortboundary; while ( insertval < 53 data[ insertpos-1 ] ) { data[ insertpos ] = data[ insertpos-1 ]; insertpos = 54 insertpos-1; } data[ insertpos ] = insertval; } /* Replace original lower-boundary 55 element */ data[ firstelement-1 ] = lowerboundary; } Team Code Orange 7

21 for ( 77 int sortboundary = firstelement+1; 78 sortboundary <= lastelement; 79 sortboundary++ 80 ) { 81 int insertval = data[ sortboundary ]; 82 int insertpos = sortboundary; 83 while ( insertval < data[ insertpos-1 ] ) { 84 data[ insertpos ] = data[ insertpos-1 ]; 85 insertpos = insertpos-1; 86 } 87 data[ insertpos ] = insertval; 88 } Beispiel für schlecht lesbaren Code Team Code Orange 8

22 120 for ( int sortboundary = firstelement + 1; sortboundary <= lastelement; 121 sortboundary++ ) { 122 int insertval = data[ sortboundary ]; 123 int insertpos = sortboundary; 124 while ( insertval < data[ insertpos - 1 ] ) { 125 data[ insertpos ] = data[ insertpos - 1 ]; 126 insertpos = insertpos - 1; 127 } 128 data[ insertpos ] = insertval; 129 } 130 // Replace original lower-boundary element 131 data[ firstelement - 1 ] = lowerboundary; 132 } Beispiel für schlecht lesbaren Code Quelle: Code Complete - von Steve McConnell Team Code Orange 9

23 Tipps Code sollte ab der ersten Zeile gemessen werden Der gesunde Menschenverstand sollte nicht ausgeschaltet werden Die Sinnhaftigkeit sollte im Einzelfall überprüft werden Team Code Orange 10

24 Checkstyle in Eclpise Team Code Orange 11

25 Inhalt JavaNCSS Features NCSS CCN Fazit Quellen Team Code Orange 1

26 JavaNCSS JavaNCSS ist ein Kommandozeilen Programm Die Metriken, die von JavaNCSS ermittelt werden, sind : NCSS(Non Commenting Source Statements) CCN(Cyclomatic Complexity Number) JVDC(Number of formal Javadoccomments) NCSS und JVDC können auf Global-, Klasse- oder Funktions-Ebene angewendet werden. Team Code Orange 2

27 NCSS Es wird die Anzahl, der Ausführbaren Codezeilen (Non-Commenting-Source-Statements) ermittelt Vereinfacht kann man sagen, dass diese Metrik die ; und die { in Java Quelltexten zählt Nicht gezählt werden leere Statements, leere Blöcke oder Semikolons nach geschweiften Klammern Kommentare und Formatierung spielen keine Rolle Team Code Orange 3

28 NCSS Vorteile : Genauer als LOC Ermöglicht Vergleichbarkeit, zu anderen Projekten Nachteile : Die Anzahl der NCSS, müssen immer im Kontext gesehen werden Alleinstehend nicht sehr aussagekräftig Team Code Orange 4

29 CCN Die von McCabe definierte Metrik ermittelt die strukturelle Komplexität (Cyclomatic Complexity Number), einer Methode oder einer Funktion. Eine Methode oder Funktion hat per Definition der Metrik, eine Komplexität mit dem Wert 1. Dieser CCN-Wert erhöht sich bei jedem Entscheidungspunkt um den Wert 1. Gibt die Anzahl der mindestens benötigten Testfälle an Team Code Orange 5

30 Einordnung der CCN In Untersuchungen von von McCabe und Halstead wurde nachgewiesen, dass ein signifikanter Zusammenhang zwischen der Komplexität und der Anzahl der Fehler, die beim Testen und im Betrieb gefunden wurden besteht. CCN Einordnung 1-10 Einfaches Programm, mit geringem Risiko Komplexeres Programm, mit moderatem Risiko Komplexes Programm, mit hohem Risiko > 50 Instabiles Programm,mit sehr hohem Risiko Team Code Orange 6

31 Beispiel CCN Berechnung public void demomethode(int wert){ } if(wert > 0) for(int i = 0; i<wert; i++) System.out.println("aaaaaaaah!"); else do{ System.out.println("bbbbbbbbbb!");} while(false); // Die CCN dieser Methode ist 4 Team Code Orange 7

32 Fazit Vorteile : CCN kann Hinweise auf Probleme in der Architektur geben JVDC zeigt fehlende Dokumentationen an Nachteile : Die Kommentar-Metrik sagt nichts über die Qualität der Kommentare aus CCN berücksichtigt nur ein Programmgerüst und lässt die Komplexität einzelner und verschachtelter Anweisungen außer acht Team Code Orange 8

33 Quellen JavaNCSS Homepage Messen & Metriken Ist Qualität messbar? METRIKEN IM PRAKTISCHEN EINSATZ Software Komplexität Team Code Orange 9

34 FindBugs FindBugs Vortragender: Felix Kaminski Team Code Orange 1

35 Inhalt von FindBugs Allgemeine Beschreibung Was kann es? Was kann es nicht? Bug Kategorien Beispiele Null-Pointer Annotations Live Team Code Orange 2

36 Allgemeine Beschreibung Fokus: echte Bugs und Performance- Probleme finden Durchsuchen des (Java) Bytecodes mittels statischer Code-Analyse nach Fehlermustern ( bug pattern ) Drei verschiedene Ausführungsarten: Kommandozeile Eigenständige GUI Plugin für Entwicklungsumgebungen Team Code Orange 3

37 Was kann es? Finden von Bugs (200+) vor der Ausführung Kein Quellcode nötig, da Durchsuchung von Bytecode Priorisierung von Bugs Erweiterbar durch eigene Bugs Integration in Build-Prozess (ANT) Export als XML (HTML) möglich Team Code Orange 4

38 Was kann es nicht? Eigene Überlegungen ersetzen Nicht alle Bugs sind Bugs Funktionalität wird nicht getestet..nur Java Team Code Orange 5

39 Bug Kategorien Unterteilung der Bugs in 10 Kategorien Gezieltes Suchen nach bestimmten Kategorien Team Code Orange 6

40 Kategorie: Dodgy Team Code Orange 7

41 Kategorie: Security Team Code Orange 8

42 Beispiel: Null-Pointer Eclipse erkennt Null-Pointer Dereferenzierung nicht Fehler zur Laufzeit! Team Code Orange 9

43 Beispiel: Null-Pointer Auswertung mit Findbugs Erkennung vor Ausführung Team Code Orange 10

44 Beispiel: Annotations Fehlererkennung durch Annotations Benötigt werden annotations.jar und jsr305.jar (Findbugs-Ordner/libs/) Team Code Orange 11

45 Beispiel: Annotations Team Code Orange 12

46 Quellen FindBugs Hompage - Erklärung des Eclipse-Plugins - IBM Tutorial zu FindBugs - Team Code Orange 13

47 Code-Metriken Teil II The overview pyramid Abstractness/Instability Chart Tools Team Code Orange 1

48 Overview Pyramid: Basisstruktur Charakterisierung der Struktur eines Systems Größe & Komplexität Verwendung der Vererbung Kopplung Team Code Orange 2

49 Overview Pyramid: Größe und Komplexität I Direkt erfassbare Kennzahlen CYCLO: zyklomatische Komplexität ( JavaNCSS) LOC: (Executable) Lines of Code NOM: Number of Methods NOC: Number of Classes NOP: Number of Packages Team Code Orange 3

50 Overview Pyramid: Größe und Komplexität II Abgeleitete Kennzahlen Intrinsic operation complexity (CYCLO/LOC) Operation structuring (LOC/NOM) Class structuring (NOM/NOC) High-Level structuring (NOC/NOP) Granularität des Systems Team Code Orange 4

51 Overview Pyramid: Kopplung Direkt erfassbare Kennzahlen FANOUT: Zahl der aufgerufenen Klassen CALLS: Zahl der Methoden-Aufrufe Abgeleitete Kennzahlen: Coupling disperson (FANOUT/CALLS): Wie stark sind die Klassen gekoppelt? Coupling intensity (CALLS/NOM) : Wie viele andere Operationen werden von einer Operation aus aufgerufen? Team Code Orange 5

52 Overview Pyramid: Vererbung Direkt erfassbare Kennzahlen AHH: Average Hierarchy Height (Tiefe des Vererbungsbaums) ANDC: Average Number of Derived Classes (Breite des Vererbungsbaums) Team Code Orange 6

53 Overview Pyramid: Beispiel PHP: Zend Framework Team Code Orange 7

54 Abstractness/Instability Chart Abhängigkeiten eines Paketes Ca: Afferent Coupling (incoming dependencies) Anzahl der Packages, die von Klassen innerhalb des Packages abhängen Ce: Efferent Coupling (outgoing dependencies) Anzahl der Packages, von denen Klassen innerhalb des Packages abhängen Beispiel: Package b Ca = 1 Ce = 2 Team Code Orange 8

55 Instability eines Package Instability I I = Ce Ce Ca [0,1] Bedeutung Von wie vielen anderen Packages hängt ein Package ab? Je mehr fremde Packages benutzt werden, umso größer die Instabilität. Instabil (I = 1): leicht änderbar Stabil (I = 0): schwer änderbar Team Code Orange 9

56 Abstractness eines Package Abstractness A A = ac ac cc [0,1] ac: Anzahl an abstrakten Klassen / Interfaces cc: Anzahl aller Klassen Team Code Orange 10

57 Abstractness/Instability Chart Abstractness/Instability Chart Team Code Orange 11

58 Abstractness/Instability Chart: Beispiel PHP: Zend Framework Team Code Orange 12

59 Tools Java JDepend (A/I Chart): auch als Eclipse-Plugin IPlasma (Overview pyramid) PHP PHP Depend (Overview pyramid + A/I Chart) Team Code Orange 13

60 Quellen / Abbildungsverzeichnis Quellen Tool-gestütztes Architekturmanagement in J2EE-Projekten Using the Overview Pyramid How reusable, extensible and maintainable is your software? Software-Metriken Abbildungen Übersicht Overview Pyramid : Team Code Orange 14

61 Cobertura Einführung Features Beispiel Integration in den Build-Prozess Demo Team Code Orange 1

62 Cobertura Einführung: la cobertura, spanisch für Abdeckung (von JCoverage) freies Java-Tool zur Berechnung der JUnit Testabdeckung zeigt ungetesteten oder unerreichbaren Code auf Team Code Orange 2

63 Cobertura Features zeigt den Anteil der getesteten Codezeilen von Klassen, Paketen oder dem Projekt zeigt die zyklomatische Komplexität von Klassen, Paketen oder dem Projekt generiert Reports in HTML oder XML kann über Kommandozeile oder von Buildern ausgeführt werden führt die Tests auf java bytecode aus Team Code Orange 3

64 Cobertura Beispiel: Team Code Orange 4

65 Cobertura Integration in den Build-Prozess: Einschub: Build-Tools wie make, Apache-Ant oder Apache-Maven automatisieren Vorgänge wie: - Kompilierung - Test - Installation von Software Team Code Orange 5

66 Cobertura Integration in den Build-Prozess: Einschub: Apache-Ant Java Build-Tool Open Source Another Neat Tool XML-gesteuert (Standard: build.xml ) Eclipse-Integration Team Code Orange 6

67 Cobertura Integration in den Build-Prozess: Einschub: Apache-Ant Grundstrukturen der XML: Project Targets wie build oder clean Tasks (über 150 mitgeliefert; selbst implementierbar): Javac (Kompilieren von Quellcode) Copy, Delete, Move Cvs (CVS-Operationen) Mail (Versenden von s) Junit Properties (z.b. zum Pfade setzen) Team Code Orange 7

68 Cobertura Integration in den Build-Prozess: build.xml für Cobertura (demo): Team Code Orange 8

69 Cobertura Integration in den Build-Prozess: Starten des Builds (demo): Team Code Orange 9

70 Cobertura Quellen und hilfreiche Links: Team Code Orange 10