Die Macht der Zahlen

Die Macht der ZahlenSoftware-Metriken mit Open Source Werkzeugen Gerrit Beine mail@gerritbeine.com 1

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

Wie alles begann... 3

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

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

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

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

Was lernen wir daraus?Wer nur 80% anstrebt erreicht davon auch nur 80%! (Insgesamt sind das dann 64%) 8

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

Warum nur Open Source Werkzeuge? 10

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

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

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

Tools & Tipps 14

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

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

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

Beispiel einer PMD-Regel 18

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

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 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

Kommunikation & Anwendung von Metriken 26

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

Viel Spaß noch! Gerrit Beine Stadtparking 18 08523 Plauen http://www.gerritbeine.com/ 28

Die Macht der Zahlen

by Gerrit Beine

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 631

Statistics

Die Macht der Zahlen Presentation Transcript

http://gerritbeine.com	630
http://gerritbeine.com&_=1341561264067 HTTP	1