die macht der zahlen
Post on 26-Jun-2015
1.752 Views
Preview:
DESCRIPTION
TRANSCRIPT
1
Die Macht der Zahlen
Software-Metriken mit Open Source Werkzeugen
Gerrit Beinemail@gerritbeine.com
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
3
Wie alles begann...
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!
5
Und dann geschah Folgendes...
1 // ... 2 3 /** 4 * Delegates to privateMethod 5 */ 6 public void doSomething() { 7 this.doSomethingReally(); 8 } 9 10 private void doSomethingReally() {11 12 }13 14 // ...
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!
7
Jetzt passierte dies:
1 // ... 2 3 /** 4 * Return X 5 */ 6 public int getX() { 7 return this.x; 8 } 9 10 /**11 * Return Y12 */13 public int getY() {14 return this.Y;15 }16 17 // ...18 19 public void doSomethingExtremeComplex() {20 21 }22 23 // ...
8
Was lernen wir daraus?
Wer nur 80% anstrebt erreicht davon auch nur 80%! (Insgesamt sind das dann 64%)
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
10
Warum nur Open Source Werkzeuge?
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
12
Der Maintainability Index
Die Formel
M I =171 5, 2 × ln(aveV )−
0, 23 × aveVG2− 16, 2 × ln(aveLOC)−
● MI < 65: sehr schlechte Qualität● 65 < MI < 85: mittlere Qualität● 85 < MI: sehr gute Qualität
● Für ein Projekt ermittelter Wert (mit proprietärem Tool): 165
● Das muss ein gutes Projekt sein!
● Von Hand berechnet: 28
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!
14
Tools & Tipps
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
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
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
18
Beispiel einer PMD-Regel
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>
20
Beispiel Martin-Metriken
21
Verteilung der Abstraktheit
22
Verteilung der Instabilität
23
Martin-Distanz
24
Auswählen von Metriken
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
26
Kommunikation & Anwendung von Metriken
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
28
Viel Spaß noch!
Gerrit Beine
Stadtparking 18
08523 Plauen
http://www.gerritbeine.com/
top related