Die Macht der ZahlenSoftware-Metriken mit Open Source Werkzeugen             Gerrit Beine            mail@gerritbeine.com ...
Ziel des Vortrags●   Pro und Contra von Softwaremessungen abwägen●   Vorstellungen vermitteln, darüber     ●   was Metrike...
Wie alles begann...                      3
Wie alles begann...●   Gegeben sei ein Projekt mit relativ hoher Mitarbeiterfluktuation●   Neue Mitarbeiter benötigen lang...
Und dann geschah Folgendes... 1   // ... 2 3   /** 4     * Delegates to privateMethod 5     */ 6   public void doSomething...
Wir geben nicht auf●   Die Erkenntnis: So wird das nix!●   Der nächste Schritt: alle Methoden müssen dokumentiert werden!●...
Jetzt passierte dies: 1   // ... 2 3   /** 4     * Return X 5     */ 6   public int getX() { 7        return this.x; 8   }...
Was lernen wir daraus?Wer nur 80% anstrebt erreicht davon auch nur 80%!         (Insgesamt sind das dann 64%)             ...
Wie es weiter ging...●   Beschluss, dass alle Klassen, Schnittstellen, Methoden und Attribute zu 100%    dokumentiert werd...
Warum nur Open Source Werkzeuge?                                   10
Warum nur Open Source Werkzeuge?●   Der wichtigste Grund: Transparenz●   Außerdem: Verfügbarkeit●   Metriken, die nicht ve...
Der Maintainability Index     Die Formel                 ●   MI < 65: sehr schlechte Qualität                             ...
Maintainability Index            ●   Die Anwendung enthält nur 35 Entitäten            ●   Die Sicht links ist die Package...
Tools & Tipps                14
Tools & Tipps●   Vergesst die LOC – Lines of Code interpretiert jeder anders!●   Stattdessen besser: NCSS – Non Commenting...
Wie ermittelt man diese Werte?●   Unter Java     ●   PMD (http://pmd.sourceforge.net/)         Source Code Analyse, Regelb...
Wie ermittelt man diese Werte?●   Unter PHP     ●   PHP Depend (http://pdepend.org/)         Pendant zu JDepend     ●   PH...
Beispiel einer PMD-Regel                           18
new DateTime() mit PMD verbieten 1   <rule name="DontUseNewDateTime" 2     message="Use of new DateTime() is not allowed" ...
Beispiel Martin-Metriken                           20
Verteilung der Abstraktheit                              21
Verteilung der Instabilität                              22
Martin-Distanz                 23
Auswählen von Metriken                         24
Auswählen von Metriken●   Auswahl ist im Allgemeinen nicht trivial●   Nicht jede Metriken passt zu jedem Projekt oder Entw...
Kommunikation & Anwendung von Metriken                                         26
Kommunikation & Anwendung von Metriken●   Metriken bieten Chancen und bergen Gefahren●   Metriken müssen abgestimmt und ve...
Viel Spaß noch!            Gerrit Beine            Stadtparking 18            08523 Plauen            http://www.gerritbei...
Upcoming SlideShare
Loading in...5
×

Die Macht der Zahlen

1,806

Published on

Die Folien meines Vortrags von den Chemnitzer Linux Tagen 2012 zum Thema Software-Metriken mit Open Source Tools

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,806
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
12
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Die Macht der Zahlen

  1. 1. Die Macht der ZahlenSoftware-Metriken mit Open Source Werkzeugen Gerrit Beine mail@gerritbeine.com 1
  2. 2. Ziel des Vortrags● Pro und Contra von Softwaremessungen abwägen● Vorstellungen vermitteln, darüber ● was Metriken im positiven Sinne bewirken können und ● was Metriken in Projekten anrichten können● Einige Tools vorstellen, die sich gut zur Erstellung von Metriken eignen● Einen Überblick schaffen und zum Einsatz von Metriken motivieren● Was nicht im Vortrag behandelt wird ● Laufzeitmetriken, Testmetriken und Anforderungsmetriken ● Details zu den vorgestellten Metriken ● Details zu den vorgestellten Tools 2
  3. 3. Wie alles begann... 3
  4. 4. Wie alles begann...● Gegeben sei ein Projekt mit relativ hoher Mitarbeiterfluktuation● Neue Mitarbeiter benötigen lange, um sich einzuarbeiten● Die erste Frage: Warum?● Die Antwort: Weil alles so kompliziert ist!● Die Lösung: Wir dokumentieren!● Aber Moment...● Dokumentieren ist aufwändig und kostet Zeit● Niemand macht es gerne● Die bessere Lösung: Wir dokumentieren nur die Public API! 4
  5. 5. Und dann geschah Folgendes... 1 // ... 2 3 /** 4 * Delegates to privateMethod 5 */ 6 public void doSomething() { 7 this.doSomethingReally(); 8 } 910 private void doSomethingReally() {1112 }1314 // ... 5
  6. 6. Wir geben nicht auf● Die Erkenntnis: So wird das nix!● Der nächste Schritt: alle Methoden müssen dokumentiert werden!● Aber Moment...● Die 80/20 Regel sagt, dass wir eh nur 80% schaffen!● Die bessere Lösung: 80% aller Methoden müssen dokumentiert werden! 6
  7. 7. Jetzt passierte dies: 1 // ... 2 3 /** 4 * Return X 5 */ 6 public int getX() { 7 return this.x; 8 } 910 /**11 * Return Y12 */13 public int getY() {14 return this.Y;15 }1617 // ...1819 public void doSomethingExtremeComplex() {2021 }2223 // ... 7
  8. 8. Was lernen wir daraus?Wer nur 80% anstrebt erreicht davon auch nur 80%! (Insgesamt sind das dann 64%) 8
  9. 9. Wie es weiter ging...● Beschluss, dass alle Klassen, Schnittstellen, Methoden und Attribute zu 100% dokumentiert werden müssen.● Aber Moment...● Auf den Inhalt kommt es an!● Was eine Methode macht, kann ein Entwickler selbst sehen.● Das Warum ist entscheidend● Also statt Prosa-Text einen Link auf die User Story oder das Requirement, die die Methode, Klasse... begründen● Erreicht: 93% Dokumentation (gemessen)● Neue Entwickler waren nach zwei Wochen fit 9
  10. 10. Warum nur Open Source Werkzeuge? 10
  11. 11. Warum nur Open Source Werkzeuge?● Der wichtigste Grund: Transparenz● Außerdem: Verfügbarkeit● Metriken, die nicht verstanden werden (können), werden in Frage gestellt● Metriken, die nicht jeder selbst anwenden kann, sind zu schwerfällig● Open Source Werkzeuge sind frei verfügbar und machen transparent was sie tun 11
  12. 12. Der Maintainability Index Die Formel ● MI < 65: sehr schlechte Qualität ● 65 < MI < 85: mittlere Qualität ● 85 < MI: sehr gute Qualität MI=171 − 5, 2 × ln(aveV ) ● Für ein Projekt ermittelter Wert (mit − 0, 23 × aveVG2 proprietärem Tool): 165− 16, 2 × ln(aveLOC) ● Das muss ein gutes Projekt sein! ● Von Hand berechnet: 28 12
  13. 13. Maintainability Index ● Die Anwendung enthält nur 35 Entitäten ● Die Sicht links ist die Package-Ebene ● Die durchschnittliche Anzahl von Abhängigkeiten pro Package ist 35 ● Was ist der Maintainability-Index in dem Fall wert? ● Das Bild versteht jeder, die 165 nicht! 13
  14. 14. Tools & Tipps 14
  15. 15. Tools & Tipps● Vergesst die LOC – Lines of Code interpretiert jeder anders!● Stattdessen besser: NCSS – Non Commenting Source Statements als Meßgrundlage● Interessante Fakten ● avg NCSS / Klasse ● avg NCSS / Methode ● avg Complexity / Methode ● avg Warnings / NCSS ● avg Errors / NCSS ● Abdeckungsgrad der API-Dokumentation● Wichtig dabei sind die Trends!● Metriken immer mit Code Reviews verbinden 15
  16. 16. Wie ermittelt man diese Werte?● Unter Java ● PMD (http://pmd.sourceforge.net/) Source Code Analyse, Regelbasiert, Komplexität und Fehlersuche ● FindBugs (http://findbugs.sourceforge.net/) Byte Code Analyse, Musterbasiert, Fehlersuche ● JavaNCSS (http://www.kclee.de/clemens/java/javancss/) Source Code Analyse, Fakten sammeln ● CheckStyle (http://checkstyle.sourceforge.net/) Source Code Analyse, Regelbasiert, Komplexität und Konventionen ● JDepend (http://clarkware.com/software/JDepend.html) Byte Code Analyse, Abhängigkeiten, Martin-Metriken ● OOMetrics & DependencyFinder (http://depfind.sourceforge.net/) Byte Code Analyse, Abhängigkeiten, Martin-Metriken, Chidamber & Kemerer ● Sonar (http://www.sonarsource.org/) Qualitäts-Management, integriert etliche der genannten Werkzeuge 16
  17. 17. Wie ermittelt man diese Werte?● Unter PHP ● PHP Depend (http://pdepend.org/) Pendant zu JDepend ● PHP Mess Detector (http://phpmd.org/) Pendant zu PMD bzw. CheckStyle, haupsächlich an PMD angelehnt ● PHP_CodeSniffer (http://pear.php.net/package/PHP_CodeSniffer) Pendant zu CheckStyle● Unter Perl ● use strict; use warnings; ● Perl::Critic (siehe Vortrag von Renée Bäcker aus dem letzten Jahr) ● Perl::Metrics, Perl::Metrics::Lite, Perl::Metrics::Simple 17
  18. 18. Beispiel einer PMD-Regel 18
  19. 19. new DateTime() mit PMD verbieten 1 <rule name="DontUseNewDateTime" 2 message="Use of new DateTime() is not allowed" 3 class="net.sourceforge.pmd.rules.XPathRule"> 4 <description> 5 New DateTime object should be created using DateTimeFactory 6 </description> 7 <properties> 8 <property name="xpath"> 9 <value>10 <![CDATA[11 //VariableDeclarator[../Type[@Array=false]]12 //AllocationExpression/ClassOrInterfaceType[@Image=DateTime] |13 //Statement//AllocationExpression/ClassOrInterfaceType[@Image=DateTime]14 ]]>15 </value>16 </property>17 </properties>18 <priority>3</priority>19 <example>20 <![CDATA[21 /* example code */22 ]]>23 </example>24 </rule> 19
  20. 20. Beispiel Martin-Metriken 20
  21. 21. Verteilung der Abstraktheit 21
  22. 22. Verteilung der Instabilität 22
  23. 23. Martin-Distanz 23
  24. 24. Auswählen von Metriken 24
  25. 25. Auswählen von Metriken● Auswahl ist im Allgemeinen nicht trivial● Nicht jede Metriken passt zu jedem Projekt oder Entwickler● Gute Strategie ist GQM (Goal – Question – Metric) ● Zuerst Ziel festlegen ● Dann konkrete Frage(n) formulieren ● Schließlich Metrik(en) auswählen, die diese formale Antwort gibt● Eine gute Einführung liefert Wikipedia: http://de.wikipedia.org/wiki/Goal_Question_Metric 25
  26. 26. Kommunikation & Anwendung von Metriken 26
  27. 27. Kommunikation & Anwendung von Metriken● Metriken bieten Chancen und bergen Gefahren● Metriken müssen abgestimmt und verstanden sein● Metriken liefern immer nur Indizien● Metriken, die mit absoluten Zahlen arbeiten, sollten immer im Trend betrachtet werden● Abweichungen identifizieren und begründen – oder eliminieren● Es gibt nur drei Arten von Problemen ● Bedrohende – für die gilt Null-Toleranz ● Unschönheiten – für die gilt eine Obergrenze, z.B. 8% der NCSS ● Egales – das sollte unbedingt ignoriert werden● Tools sollten in den Entwicklungsprozess integriert werden ● Continuous Integration z.B. in Jenkins & Co. ● Ins Source Code Repository, z.B. über den pre-commit Hook von Subversion 27
  28. 28. Viel Spaß noch! Gerrit Beine Stadtparking 18 08523 Plauen http://www.gerritbeine.com/ 28
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×