1. 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

2. 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://Sebastian.Dietrich@e-movimento.com
 http://managing-java.blogspot.co.at
 http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich
► www.e-movimento.com, Sebastian Dietrich2

3. 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?
► www.e-movimento.com, Sebastian Dietrich3
[DeMarco 82]
7%
67%
13%
5%
8%
Analyse
Design
Codierung
Testen
Wartung

4. 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]
► www.e-movimento.com, Sebastian Dietrich4
[DeMarco 82]

5. 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
► www.e-movimento.com, Sebastian Dietrich5
Hochsprung, Olympische Spiele 1928
„moreofthesame“
„unkonventionell“

6. Unkonventionelle Ansätze
In der Architektur
► www.e-movimento.com, Sebastian Dietrich6
Stein
Betonfundament
Eisen Stahl
Stahlbeton
Industrielle Fertigung (1-6 Jahre)

7. Unkonventioneller Ansatz #1:
„Arbeite professionell“
 Frage: Wer ist Anfänger - Junior, wer ist Senior - Experte?
► www.e-movimento.com, Sebastian Dietrich7

8. Unkonventioneller Ansatz #1:
„Arbeite professionell“
 Traurige Realität in der Informatik:
► www.e-movimento.com, Sebastian Dietrich8

9. „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
► www.e-movimento.com, Sebastian Dietrich9
Robert C. Martin:
„Demanding Professionalism
in Software Development“
http://www.youtube.com/watch?v=p0O1VVqRSK0

10. „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
► www.e-movimento.com, Sebastian Dietrich10
CCD Armbänder
Konsequenz genug?

11.  Typische Projektdokumente:
 Warum dokumentieren wir?
Reflexion, Kommunikation, Absicherung
Dokumentation
Warum dokumentieren wir?
► www.e-movimento.com, Sebastian Dietrich11
Lastenheft
Pflichtenheft
Funktionale Spezifikation
Nicht-Funktionale Spezifikation
Usecases
Stories
ObjektmodelleProjektauftrag
ProjektplanungProjektumweltanalyse
Projektrisikoanalsye
Projektfortschrittsbericht
Projekttagebuch
Projektstrukturplan
UML-Diagramme
GlossarSchnittstellendefinition
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
ProjektzieldefinitionArbeitspaketspezifikation
To-Do-ListenMeetingprotokolle
Meetingagenden
Projektfunktionendiagramm

12. 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
► www.e-movimento.com, Sebastian Dietrich12

13. Unkonventioneller Ansatz #2:
„Dokumentiere nichts – kommuniziere lieber“
► www.e-movimento.com, Sebastian Dietrich13
 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);
...

14. „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) {
...
► www.e-movimento.com, Sebastian Dietrich14

15. „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
► www.e-movimento.com, Sebastian Dietrich15

16. 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?
► www.e-movimento.com, Sebastian Dietrich16
Performancetests
Securitytests
Penetrationtests
Integrationstests
Systemtests
Loadtests
Abnahmetests
Usablity Test
Unit-Tests
Lasttests
Regressiontests
Fehlertests
Schnittstellentests
Installationstests
Crashtests
Smoketests
Stresstests

17. 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.
► www.e-movimento.com, Sebastian Dietrich17
[Jones 86], [Jones 96a], [Jones 96b], [Shull 02], [McConnell 04]

18. 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.
► www.e-movimento.com, Sebastian Dietrich18
[Jones 01], [Humphrey 89], [Software Metrics 01]

19. 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.)
► www.e-movimento.com, Sebastian Dietrich19

20. 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
► www.e-movimento.com, Sebastian Dietrich20
Moskitonetz –
Verhindert Bugs

21. „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
► www.e-movimento.com, Sebastian Dietrich21

22. 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
► www.e-movimento.com, Sebastian Dietrich22

23. 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
► www.e-movimento.com, Sebastian Dietrich23
PMD
CPD
Checkstyle Sonargraph
Sotograph
Simian
JDepend
NDepend
Macker
FindBugs
Lint
CppCheck
FXCop
Axivion
NCSS
CMT
UCDetector
CRAP
Sonar Build Breaker Plugin

24. ► www.e-movimento.com, Sebastian Dietrich24
Vielen Dank für Ihre Aufmerksamkeit!
Q&A[Sebastian Dietrich]
Sebastian.Dietrich@e-movimento.com
http://managing-java.blogspot.com