Mastering architecture, design- and code-quality

e-movimento Software Design & Beratung GmbH

1030 Wien ● Marxergasse 7/26 ► www.e-movimento.com

Mastering Architecture-, Design- and

Code-Quality

Unkonventionelle Ansätze zur

Produktivitätssteigerung

Vorstellung

Name: DI Sebastian Dietrich

Tätigkeiten:

Java-Softwareentwickler & Softwarearchitekt

Lead-Developer, Scrum-Master

Berater, Trainer

Überzeugungen & Leidenschaften:

Technische Qualität Produktivität

Praxiserfahrung & theoretischer Background

Agile Softwareentwicklung, Java, Android, Wikipedia

Kontakt:

mailto://[email protected]

http://managing-java.blogspot.co.at

http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich

► www.e-movimento.com, Sebastian Dietrich

2

mailto:[email protected]



http://managing-java.blogspot.co.at/



http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich

Technische Qualität vs. Produktivität

Frage:

Wieviel Zeit kostet hohe

technische Qualität in der

Softwareentwicklung?

Wieviel Zeit bringt hohe

technische Qualität in der

Wartungsphase?

Antwort: Die Frage ist falsch:

Wartung beginnt mit der Analyse

Technische Qualität spart (auch

während der Entwicklung) Zeit ein.

Richtige Frage:

Wieviel Zeit/Geld/Kunden kostet uns schlechte technische Qualität?


3

[DeMarco 82]

7%

67%

13%

5%

8%

Analyse

Design

Codierung

Testen

Wartung

7%

67%

13%

5%

8%

Analyse

Design

Codierung

Testen

Wartung

7%

13%

5%

6%

53%

16%

Analyse

Design

Codierung

Testen

Wartung

Ersparnis

Kosten schlechter technischer Qualität = „Technische Schuld“

Technische Schuld =

„Zusätzlicher Aufwand, den man für

Änderungen und Erweiterungen an

schlecht geschriebener Software im

Vergleich zu gut geschriebener Software

einplanen muss.“

Kosten Technischer Schuld:

+ 5-10% Entwicklungsaufwand

+ 20-40% Test &

Fehlerbehebungsaufwand

+ 20% Wartungsaufwand

+ verlorene Umsätze & Kunden

[McConnel 2003], [Wiegers 2002], [Jones 2000],

[Gilb and Graham 1993], [Humphrey 1998],

[Fagan 1976]


4

[DeMarco 82]

Technische Schuld Warum unkonventionelle Ansätze?

Personelle Ansätze:

„Bessere Entwickler“

„Bessere QS-Tools“

„Mehr Zeit für QS“

„Bessere PMs“

Klassische Ansätze:

Code-reviews

Statische Code-Analyse

„moderne“ Ansätze

Pair Programming

Test Driven Development


5

Hochsprung, Olympische Spiele 1928

„mo

re o

f th

e s

am

e“

„unkonventionell“

Unkonventionelle Ansätze In der Architektur


6

Stein

Betonfundament

Eisen Stahl

Stahlbeton

Industrielle Fertigung (1-6 Jahre)

Unkonventioneller Ansatz #1: „Arbeite professionell“

Frage: Wer ist Anfänger - Junior, wer ist Senior - Experte?


7

Unkonventioneller Ansatz #1: „Arbeite professionell“

Traurige Realität in der Informatik:


8

„Arbeite professionell“ Forderungen an professionelle Entwickler

Software Professionalism:

We will not ship shit

We will always be ready

Stable productivity

Inexpensive adaptability

Continuous improvement

Fearless competence

Extreme quality

QA will find nothing

We cover for each other

Honest estimates

Say „No“

Automation

Continuous Aggressive Learning

Mentoring


9

Robert C. Martin:

„Demanding Professionalism

in Software Development“

http://www.youtube.com/watch?v=p0O1VVqRSK0

http://www.youtube.com/watch?v=p0O1VVqRSK0

„Arbeite professionell“ Konsequenzen für professionelle Entwickler

1. Frage nicht, tue es!

Jesuitenprinzip nach Dave Burns:

„Um Verzeihung bitten ist einfacher,

als um Erlaubnis zu fragen“

Ein Professionist fragt nicht, ob er

professionell arbeiten darf!

2. Ignoriere diesbezüglich Projektleiter!

Projektleiter sind Projektleiter & keine

Nachhilfelehrer

Einmischung in Arbeitsweise =

Micromanagement = Antithese zu

Projektleitung

3. Ignoriere diesbezüglich Kunden!

Kunden sind nicht für das „wie“ verantwortlich


10

CCD Armbänder

Konsequenz genug?

Typische Projektdokumente:

Warum dokumentieren wir?

Reflexion, Kommunikation, Absicherung

Dokumentation Warum dokumentieren wir?


11

Lastenheft

Pflichtenheft Funktionale Spezifikation

Nicht-Funktionale Spezifikation

Usecases

Stories

Objektmodelle Projektauftrag

Projektplanung Projektumweltanalyse

Projektrisikoanalsye

Projektfortschrittsbericht

Projekttagebuch

Projektstrukturplan

UML-Diagramme

Glossar Schnittstellendefinition

Architekturbeschreibung

Datenbankmodell

Code-Kommentare

Javadoc ToDos, FIXMEs, XXX

Tasks

Code-Reviews

CheckIn Kommentare

Schnittstellenbeschreibungen

Testpläne

Testdesign-Spezifikation

Testfälle

Testlog

Testabschlussberichte

Bug-Reports

Feature-Requests

Benutzerhandbücher

Anwender-Tutorials

Abnahmeprotokolle

Installationshandbuch

Betriebshandbuch

Projektabschlussbericht

Stundenlisten

Projektrollendefinition

Projektzieldefinition Arbeitspaketspezifikation

To-Do-Listen Meetingprotokolle

Meetingagenden

Projektfunktionendiagramm

Dokumentation Nachteile von Dokumentation

Dokumentation ist sauteuer:

Kommerzielle Softwareprojekte:

28 - 66 Seiten / KLOC [Jones 99], [Boehm 88]

Typisches großes Softwareprojekt:

100 Personenjahre Entwicklung ~1.000 KLOC

~ 28.000 – 66.000 Seiten Dokumentation

~ 10 - 40 Personenjahre Dokumentation

Üblicherweise gilt:

Dokumentationskosten > Codierungskosten

Nachteile von Dokumentation:

Dokumentation ist immer veraltet

Dokumentation ist kaum auffindbar

Dokumentation wird meist nicht gelesen


12

Unkonventioneller Ansatz #2: „Dokumentiere nichts – kommuniziere lieber“


13

Warum dokumentieren wir?

Reflexion, Kommunikation, Absicherung

Dafür gibt es geeignetere Techniken:

Brainstormings, Analyse-Sessions, CRC-Cards, Prototypen, …

echte face2face Kommunikation, Mentoring, Pair-Programming, …

Vertrauen, Collective Ownership, Tests,

Beispiel Code-Dokumentation: //fill Person from Database via Reflection

Object personFromDB = loadFromDB(id);

BeanUtils.copyProperties(person, personFromDB);

...

Warum nicht (Programming by Intention)?: fillPersonFromDatabase(person, id);

...

„Dokumentiere nichts – kommuniziere lieber“ Beispiel JavaDoc

Beispiel (Klasse Mitarbeiter):

...

/**

* Sets the name of this person.

* @param name the name of this person

* @exception IllegalArgumentException

* when name is shorter than 3 characters

*/

public void setFirstName(String name) {

if (name.length <= 3)

throw new IllegalArgumentException();

...

Alternative (via BeanValidation 1.1):

public void setFirstName(@NotNull @Size(min=4) firstName) {

...


14

„Dokumentiere nichts – kommuniziere lieber“ Konsequenzen für Entwickler

Erkenntnis:

Dokumentation ist sauteuer und bringt wenig

Es gibt bessere & günstiger Möglichkeiten fürs

Reflektieren, Kommunizieren, Absichern

Konsequenzen:

Guter Code benötigt keine Kommentare

Code Kommentare sind immer ein Smell &

Zeichen für zu hohe Komplexität [Fowler 99]

Schreibe Code der kommuniziert

Lesbarer Code, geringe Komplexität, kurze

Methoden, Programming by Intention

Gutes Design benötigt kein Javadoc

Signatur der Methoden ist Teil des Designs,

Javadoc ist nicht Teil der Signatur


15

Testen Warum testen wir?

Warum testen wir?

Warum schreiben wir Unit-Test?

Warum schreiben wir

Integrationstests?

Warum schreiben wir Testfälle?

Warum führen wir Testfälle durch?

Um Kosten zu reduzieren

Entwicklungskosten, Wartungskosten

Fehlerbehebungskosten

Imagekosten

…

Wieviel darf uns daher der Test

kosten?


16

Performancetests

Securitytests

Penetrationtests

Integrationstests

Systemtests

Loadtests

Abnahmetests

Usablity Test

Unit-Tests

Lasttests

Regressiontests

Fehlertests

Schnittstellentests

Installationstests

Crashtests

Smoketests

Stresstests

Systemtest Kosten – Nutzen Rechnung

Kosten Nutzen

Systemtestaufwand:

~ 1 PT / Testfall

Systemtest findet

~ 1 Fehler / Testfall

Fehlerbehebungsaufwand:

~ 1PT / Fehler

(10x wie während Entwicklung)

Je behobener Fehler:

0,5 – 0,8 neue (unentdeckte)

Fehler

80 – 150%

der Entwicklungskosten

Systemtest findet

max. 25 – 55% der Fehler

Systemtest:

Teststufe, bei der das gesamte System

gegen die gesamten Anforderungen getestet wird.


17

[Jones 86], [Jones 96a], [Jones 96b], [Shull 02], [McConnell 04]

Unittest Kosten – Nutzen Rechnung

Kosten Nutzen

Unit-Testaufwand:

~ 2-3x Entwicklungsaufwand

„Code Coverage“ ?

„Refactoring“ ?

Fehlerbehebungsaufwand:

~ 1h / Fehler

(1/10 wie während Test)

Je behobener Fehler:

0,5 – 0,8 neue (unentdeckte)

Fehler

~ 50% der Entwicklungskosten Unit-Test findet

max. 15 – 70% der Fehler

Unit-Tests:

Teststufe, bei der funktionale Einzelteile (Module)

auf korrekte Funktionalität geprüft werden.


18

[Jones 01], [Humphrey 89], [Software Metrics 01]

Unittests Warum gute Unittests so teuer sind

Gute Unittests (gilt auch für TDD):

Haben Assertions (die den Vertrag der Methoden testen):

Vorbedingungen (typische / untypische / extreme / unerlaubte)

Nachbedingungen (Rückgabewerte & Exceptions, State-Änderungen)

Invarianten (was sich nicht ändern darf)

Haben 100% Assertion-Coverage (Code-Coverage ist unwichtig)

Testen Units (& mocken Referenzen auf andere Units weg)

Berücksichtigen State (Quasimodale & Modale Klassen) und

Reihenfolge der Methodenaufrufe (Unimodale & Modale Klassen)

Hinterlassen das System, wie sie es vorgefunden haben

Laufen daher in beliebiger Reihenfolge

Sind Refactoring-Safe

Testen auch das Design (z.B. Liskovsches Substitutionsprinzip)

Laufen auf dem CI Server & geben rasches Feedback (< 1 min.)


19

Unkonventioneller Ansatz #3: „Teste nichts – verhindere Fehler“

Wie technische Fehler verhindern?

Test Driven Development:

Designe mittels Tests

Keine weiteren Unit-Tests &

Integrationstests mehr nötig

Reduziere State & Abhängigkeiten auf

das absolut notwendigste

Wie fachliche Fehler verhindern?

Behavior Driven Development:

Analyse mittels Tests

Keine Systemtests und

Abnahmetests mehr nötig

Entwicklung (& TDD) wesentlich

einfacher & weniger Aufwand


20

Moskitonetz –

Verhindert Bugs

„Teste nichts – verhindere Fehler“ Konsequenzen für Entwickler

Erkenntnis:

Testen ist sauteuer und bringt wenig

Es gibt bessere & günstiger Möglichkeiten um

Fehler zu verhindern

Konsequenzen:

Bestehe auf BDD Analysen (in Gherkin)

Schreibe Steps die gegen die BL testen

Definiere die Schnittstellen mittels TDD

Designe ein GUI ohne jedweder Logik

„QA will find nothing“

Konsequenzen für Tester:

Lerne Gherkin und werde Analytiker


21

Continuous Integration Warum machen wir Continuous Integration?

Warum?

Geringerer Integrationsaufwand

Automatische QS auf CI-Server

(vs. „Runs on my Machine“)

…

Was testen die Tests am CI-Server?

Unit-Tests?

Integrationstests?

Systemtests = BDD Szenarien?

Technische Qualität?

Was, wenn die technische

Qualität nicht passt?

Wir nehmen Technische Schuld auf


22

Unkonventioneller Ansatz #4: „Brich den Build – und nimm keine technische Schulden auf“

Brich den Build auch wenn die

technische Qualität nicht passt:

Architektur

Architekturverletzungen

Zyklen

Technisches Design:

Doppelter & Toter Code

Verletzung OO Designprinzipien

Wenn der Code nicht passts

Naming & Coding-Conventions

Code-Smells, mögliche Bugs

Komplexität

Wenn der Trend nicht passt

Metriken


23

PMD CPD

Checkstyle Sonargraph

Sotograph

Simian

JDepend

NDepend

Macker

FindBugs

Lint

CppCheck

FXCop

Axivion

NCSS

CMT

UCDetector

CRAP

Sonar Build Breaker Plugin


24

Vielen Dank für Ihre Aufmerksamkeit!

Q&A [Sebastian Dietrich]

[email protected]

http://managing-java.blogspot.com




Business

Mastering architecture, design- and code-quality