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!