Upload
axxessio-gmbh
View
640
Download
3
Embed Size (px)
DESCRIPTION
Diese Präsentation zeigt die technische Qualitätssicherung im Projekt und deren praktische Umsetzung und wurde von Oliver Wronka, Principal Architect/ Project Manager bei axxessio, erstellt.
Citation preview
Technische Qualitätssicherung im Projekt und deren praktische Umsetzung
OLIVER WRONKA
JANUAR 2014
Best Practise – Technische Qualitätssicherung
2
Agenda
» Inhalt» Die verschiedenen Ebenen der technischen
Qualitätssicherung» Praktische Beispiele für die Ebenen» Vorbereitende Maßnahmen» Gegenmaßnahmen
3
Inhalt
» Nicht immer wird in einem Projekt von Beginn an eine technische Qualitätssicherung aufgebaut.
» Ist dies jedoch der Fall so werden Daten geliefert, die sich nicht automatisch jedem Erschließen
» Diese Präsentation soll zum Einen einen Überblick darüber verschaffen, wie eine TQS aufgebaut ist und zum Anderen, wie mit den gewonnenen Daten umgegangen werden kann.
» Zu guter Letzt wird darauf eingegangen, wie eine schlechte, technische Qualität von vornherein vermieden werden kann bzw. wie eine Kehrtwende zum Besseren in einem Projekt erreicht werden kann.
4
Die verschiedenen Ebenen der technischen Qualitätssicherung
Die technische Qualitätssicherung kann in vier Ebenen unterteilt werden.
Man kann vier Ebenen der TQS definieren:
Codierrichtlinien: Diese geben vor wie ein Quelltext zu formatieren und zu kommentieren ist. Darüber hinaus sind häufig auch Richtlinien vorhanden die auf einen defensiven und insbesondere sicheren Programmierstil verweisen.
Statische Quellcodeanalyse: Mit Hilfe von Tools können Programmierfehler im Programmcode erkannt werden.
Testabdeckung: Mit Hilfe von automatisierten Tests können Anwendungen nicht nur zyklisch getestet werden. Darüber hinaus kann auch die dabei erreicht Testabdeckung ermittelt werden und ungetestete Codestrecken ermittelt werden.
Metriken: Metriken sind die Kür in der TQS. Wenn Code z.B. stabil gegenüber Änderungen sein soll so helfen Metriken, dies sicher zu stellen.
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
5
Praktische Beispiele – Codierrichtlinien (Kommentierung, Formatierung) Guter Code:
/** * Die Funktion calcTax berechnet * die Mehrwertsteuer zu einem * übergebenen Preis * @param price der Nettopreis * @return 19% vom Nettopreis **/ double calcTax (double price) { if (price < 0) { /* mit einem negativen Betrag können wir nichts anfangen, daher Vorzeichen umkehren */ return price * -0.19; }
return price * 0.19; }
Schlechter Code:
double c(double p){return p<0 p*-0.19:p*0.19;}
Codierrichtlinien sind die Basis und bewirken, dass Code überhaupt lesbar ist.
Die Methode ist dokumentiert
Parameter und Rückgabe sind dokumentiert
Eine Anweisung pro Zeile, Blöcke sind eingerückt.
Fachliche Anforderung und deren Umsetzung sind dokumentiert.
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
6
Praktische Beispiele – Codierrichtlinien (Defensive Programmierung) Guter Code:
int addPerson (String firstName, String lastName) { if (firstName == null || firstName.length() == 0) { return ERR_NO_FIRST_NAME; } if (lastName == null || lastName.length() == 0) { return ERR_NO_LAST_NAME; }
return db.insertPerson (firstName, lastName); }
Schlechter Code:
void addPerson (String name1, String name2) { db.insert (name1, name2); }
Codierrichtlinien führen letztendlich zu robustem Code.
Die Parameter werden geprüft. Dies ist ein
defensiver Programmierstil.
Im Fehlerfall werden eindeutige Codes
zurückgeliefert
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
7
Praktische Beispiele – Codierrichtlinien (Beispiel für einen Bericht)
Tools zur Überprüfung von Codierrichtlinien gibt es schon seit langem und sind frei verfügbar.
Dies ist ein typischer Auszug einer automatisierten Überprüfung der Codierrichtlinien. In diesem Fall
durch das frei verfügbare Checkstyle.
Hier häufige Verletzung dieser Checkstyle-Regel weist darauf hin, das der Programmierer lieber der Kreativität anhängt anstatt von Zeit zu Zeit auch mal seine geistigen Ergüsse zu
dokumentieren.
Verschärftes „DuDu“ aussprechen!
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
8
Praktische Beispiele – Statische Quellcodeanalyse
Die statische Quellcodeanalyse ist eine sinnvolle Ergänzung zu den Codierrichtlinien.
Offensichtliche Programmierfehler können toolgestützt erkannt werden.
String concat (String firstName, String lastName) throws ApplicationException { String name = firstName.toUpperCase () + lastName.toUpperCase ();
if (firstName == null || lastName == null) { throw new ApplicationException („FirstName or LastName is null“); }
return name; }
Das ist grober Unfug!
Auf beide Variablen wird im Statement zuvor bereits zugegriffen, sodass dort bereits eine Nullpointer-
Excpetion auftritt.
Die ApplicationException kann also niemals geworfen
werden.
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
9
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
MetrikenPraktische Beispiele – Statische Quellcodeanalyse (Beispiel für einen Bericht)
Diese ist in der Lage echte Programmierfehler zu finden die in der Ausführung des Programms zu schweren Fehlern führen können.
Dies ist ein typischer Auszug einer statischen Quellcodeanalyse. In diesem Fall durch das
frei verfügbare FindBugs.
Dieser Code läuft nur sofern die Anwendung
die entsprechende Verzeichnisstruktur (*)
vorfindet.
„Peitschenhiebe“ androhen!
(*) Anm. des Autors:Gilt nicht mehr bei Continious Delivery
10
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken» Alle Entwickler müssen Testfälle schreiben die später zyklisch in einer entsprechenden
Buildumgebung ausgeführt werden.» Jeder Bugfix sollte einen Testcase nach sich ziehen, was im Laufe der Zeit zu einer vollständigen
Testabdeckung führen kann.» Neben einer Übersicht zur Gesamtabdeckung können auch gezielt die Stellen identifiziert
werden, die noch durch Hinzufügen weiterer Testcases abgedeckt werden müssen.» Idealerweise werden auch Stellen erkannt, die überhaupt nicht mehr genutzt werden (fachlich toter Code).
Automatisiertes Testen und die kontinuierliche Steigerung der erreichten Testabdeckung führen zu einer wirklich fehlerfreien Anwendung.
11
Praktische Beispiele - Metriken
Metriken sind die Kür der technischen Qualitätssicherung und müssen mit Bedacht angewendet werden.
Eine geringe Anzahl von Metriken reicht, um die Qualität des Quellcodes einschätzen zu können.
Die wichtigsten Metriken sind:
MLOC: Methods Lines of Code – Anzahl der Quellcodezeilen je MethodeDiese Metrik besagt, dass die Anzahl von Quellcodezeilen je Methode z. B. unter 100 liegen sollte. Ist diese Zahl wesentlich größer so kann davonausgegangen werden, dass man eine sogenannte Gottmethode hat. Dies ist eine Methode, die eigentlich „Alles“ macht. Solche Methoden sind schwer zu warten (schon alleine deswegen, weil diese nicht auf den Monitor passen) und zu testen.
TLOC: Total Lines of Code – Anzahl der Quellcodezeilen je KlasseHierfür gilt das bereits oben gesagt für eine Klasse statt nur einer Methode
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
12
Praktische Beispiele - Metriken
NBD: Nested Block Deep – VerschachtelungstiefeEine Verletzung dieser Metrik zeigt an, dass es sich um sehr komplexen Code handelt.
Ein Beispiel:void complex (int param1, int param2, int param3, int param4, int param5) { if (param1 < 1) { if (param2 > 2) { if (param3 != 3) { if (param4 == 4) { if (param1 == param3) { /* dann tu ich was */ } else { /* dann tu ich was anderes */ } } } else { /* hm, ich glaube ich gehöre zu f (param2 > 2){ if (param5 == 5) { /* dann tu ich eben was anderes, vorausgesetzt param5 ist 5 */ } } } }}
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
13
Praktische Beispiele - Metriken
VG: McCabe Cyclomatic Complexity
Vereinfacht werden hier einfach die Anzahl der Verzweigungen je Methode gezählt.Ein Wert von über 10 weist darauf hin, dass die Methode sehr komplex ist und somit fehleranfällig.
Sehr häufig deckt diese aber auch Schwächen im Codedesign auf.
Ein Beispiel:
Häufig findet man im Code Verzeigungen die die Verarbeitung steuern basierend auf dem inneren Zustand einer Klasse.
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
14
Praktische Beispiele - Metriken
Schlechtes Design
class complex {private int zustand;
void method1 () {if (zustand
== 1) {/*
ich tue dieses */} else {
/* ich tue jenes */
}}
void method2 () {if (zustand
== 1) {/*
ich tue dieses */} else {
/* ich tue jenes */
}}
}
Gutes Design
interface simple { void method1 ();void method2 ();}
class quiteSimple implements simple {void method1 () {
/* ich tue dieses */
}
void method2 () {/* ich tue dieses
*/}
}
class verySimple implements simple {void method1 () {
/* ich tue jenes */}
void method2 () {/* ich tue jenes */
}}
int main (argv[]) {int zustand =
argv[0];Simple s;
if (zustand == 1} {s = new
quiteSimple ();} else {
s = new verySimple ();
}}
Was passiert wenn ein weiterer Zustand mit dem Wert 3 eingeführt wird ?
Codierrichtlinien
Statische Quellcodeanalyse
Testabdeckung
Metriken
15
Vorbereitende Maßnahmen
Die technische Qualitätssicherung sollte zu Beginn eines Projekts eingefordert bzw. aufgesetzt werden
» Wird ein Projekt neu ausgeschrieben, so sind die Anforderungen an die TQS in den Vertrag mit auszunehmen.
» Idealerweise wird die aufzubauende Umgebung für das Continiuos Integration beschrieben (z. B. maven zusammen mit Jenkins) und die zu erstellenden Reports (z. B. Checkstyle, FindBugs, Cobertura) beschrieben.
» Sind die Reportingmodule definiert so sollte man die zugehörigen Konfigurationsdateien (z. B. checkstyle.xml) direkt mitliefern.
» Die Konfigurationsdateien sollten im Repository (z. B. Subversion) abgelegt und versioniert werden. Dies verhindert „unbeabsichtigte“ Änderungen an den Konfigurationsdateien.
16
Gegenmaßnahmen
Ist dies nicht der Fall so kann man diese in einem laufenden Projekt einführen.
» Ist ein Projekt gestartet ohne die Anforderungen an die TQS im Vertrag festzuhalten, so können Gegenmaßnahmen wie folgt ergriffen werden:» In einem Workshop werden „Definitions of Done“ definiert und
dokumentiert.» Die DoD beinhalten eine Liste von Eigenschaften die ein
Softwareartefakt haben muss, bevor die Aufgabenstellung als „erledigt“ betrachtet werden kann.
» Die DoD sind eine freiwillige Selbstverpflichtung die nicht abnahmerelevant ist.
» Erfahrungen haben gezeigt, dass die Teams untereinander in einen Wettstreit treten, wer den besten Code schreibt.
17
Gegenmaßnahmen
» Sind die DoD etabliert so können diese nun in einem zweiten Schritt dafür genutzt werden, die Codequalität schrittweise anzuheben.» Hierzu werden die DoD nun als abnahmerelevant erklärt.» Es ist eine Baseline zu ermitteln die dokumentiert, in wie weit der
aktuelle Sourcecode die DoD nicht erfüllt.» Es ist je Release eine nichtfunktionale Anforderung einzustellen die
fordert, das 20% der Fehler zu beseitigen sind.» Nach fünf Release sollten die DoD dann erfüllt sein und zukünftig auch
eingehalten werden.
» Im Backup sind die DoD für Java beigefügt.
Backup
19
DoD Java» Der Code erfüllt alle an ihn gestellten funktionalen Anforderungen (Todos erledigt) » Der Code muss fehlerfrei kompilieren » Die Unittests müssen fehlerfrei durchlaufen. » Der Code muss vollständig eingecheckt sein. Hierzu gehören neben den eigentlichen Quellcodedateien auch die zugehörige Dokumentation
sowie die Unittests. » Der Code ist an alle relevanten Stellen gemerged. » Der Code muss den Richtlinien für Java entsprechen. Diese lauten:
» Die Codierrichtlinien für Java sind einzuhalten. Die Einhaltung dieser Richtlinien wird durch ein Maven-Checkstyle-Plugin im Rahmen der Continious Integration täglich überprüft. Die entsprechende Konfigurationsdatei ist im WiKi abgelegt unter Java_Checkstylekonfiguration und kann auch in Eclipse eingebunden werden. Die formelle Korrektheit (Einrücktiefe, Tabsize, Klammersetzung usw.) des Codes kann sichergestellt werden durch die Java Formatterkonfiguration für den Eclipse Sourcecodeformatter.
» Die Sicherheitsrelevante Codierrichtlinien für Java sind einzuhalten. Die Einhaltung dieser Richtlinien wird durch Quellcodreviews geprüft. » Der Code darf keine FindBugs-Regeln verletzen. Die Einhaltung dieser Richtlinien wird durch ein Maven-FindBugs-Plugin im Rahmen der
Continious Integration täglich überprüft. » Die Testabdeckung muss mindestens 65% auf Paketeben betragen. Die Einhaltung dieser Richtlinien wird durch ein Maven-Cobertura-Plugin im
Rahmen der Continious Integration täglich überprüft. » Es sind folgende Softwaremetriken einzuhalten
» DIT: Depth Of Inheritance Tree (Vererbungstiefe) darf nicht größer sein als 6 » MLOC: Method Lines Of Code (Anzahl Quellcodezeilen je Methode) darf nicht größer sein als 100 » TLOC: Total Lines Of Code (Anzahl Quellcodezeilen je Klasse) darf nicht größer sein als 2000 » NBD: Nested Block Deep (Verschachtelungtiefe) darf nicht größer sein als 5 » PAR: Parameter (Anzahl der Parameter je Methode) darf nicht größer sein als 5 » VG: McCabe Cyclomatic Complexity (vereinfacht ist dies die Anzahl der Verzweigungen je Methode, darf nicht größer als 10 sein. » WMC: Weighted Method Complexity ist die Summe aller VG einer Klasse, darf nicht größer sein als 50
» Die Einhaltung dieser Softwaremetriken wird durch das Eclipse-Metrics-Plugin überprüft.
Unsere Standorte
Niederlassung Köln
Wilhelmstraße 351143 KölnTel +49 22 03 – 91 22 0Fax +49 22 03 – 91 22 23
Niederlassung Darmstadt
Kasinostraße 6064293 DarmstadtTel +49 61 51 – 78 90 0Fax +49 61 51 – 78 90 23 0
Hauptsitz Bonn
Kurfürstenallee 553177 BonnTel +49 228 – 76 36 31 0Fax +49 228 –76 36 31 3
Niederlassung Bern
Frohbergweg 73012 BernTel +41 31 – 534 07 06Fax +41 31 – 536 69 78
Consider IT done!