Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
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...
Nächste SlideShare
Wird geladen in …5
×

Die Macht der Zahlen

2.198 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

×