Die Macht der Zahlen
-
Upload
gerrit-beine -
Category
Technology
-
view
1.754 -
download
3
description
Transcript of Die Macht der Zahlen
![Page 2: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/2.jpg)
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
![Page 3: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/3.jpg)
3
Wie alles begann...
![Page 4: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/4.jpg)
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!
![Page 5: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/5.jpg)
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 // ...
![Page 6: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/6.jpg)
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!
![Page 7: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/7.jpg)
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 // ...
![Page 8: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/8.jpg)
8
Was lernen wir daraus?
Wer nur 80% anstrebt erreicht davon auch nur 80%! (Insgesamt sind das dann 64%)
![Page 9: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/9.jpg)
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
![Page 10: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/10.jpg)
10
Warum nur Open Source Werkzeuge?
![Page 11: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/11.jpg)
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
![Page 12: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/12.jpg)
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
![Page 13: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/13.jpg)
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!
![Page 14: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/14.jpg)
14
Tools & Tipps
![Page 15: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/15.jpg)
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
![Page 16: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/16.jpg)
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
![Page 17: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/17.jpg)
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
![Page 18: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/18.jpg)
18
Beispiel einer PMD-Regel
![Page 19: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/19.jpg)
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>
![Page 20: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/20.jpg)
20
Beispiel Martin-Metriken
![Page 21: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/21.jpg)
21
Verteilung der Abstraktheit
![Page 22: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/22.jpg)
22
Verteilung der Instabilität
![Page 23: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/23.jpg)
23
Martin-Distanz
![Page 24: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/24.jpg)
24
Auswählen von Metriken
![Page 25: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/25.jpg)
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
![Page 26: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/26.jpg)
26
Kommunikation & Anwendung von Metriken
![Page 27: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/27.jpg)
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
![Page 28: Die Macht der Zahlen](https://reader033.fdocuments.net/reader033/viewer/2022052217/558c9146d8b42af7428b4704/html5/thumbnails/28.jpg)
28
Viel Spaß noch!
Gerrit Beine
Stadtparking 18
08523 Plauen
http://www.gerritbeine.com/