SlideShare ist ein Scribd-Unternehmen logo
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://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
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
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]
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“
Unkonventionelle Ansätze
In der Architektur
► www.e-movimento.com, Sebastian Dietrich6
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?
► www.e-movimento.com, Sebastian Dietrich7
Unkonventioneller Ansatz #1:
„Arbeite professionell“
 Traurige Realität in der Informatik:
► www.e-movimento.com, Sebastian Dietrich8
„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
„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?
 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
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
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);
...
„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
„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
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
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]
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]
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
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
„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
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
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
► 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

Weitere ähnliche Inhalte

Was ist angesagt?

Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
SwissQ Consulting AG
 
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft AG
 
Qz Req Eng Ebert Rudorfer 2011 V3
Qz Req Eng Ebert Rudorfer 2011 V3Qz Req Eng Ebert Rudorfer 2011 V3
Qz Req Eng Ebert Rudorfer 2011 V3
Arnold Rudorfer
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
OPITZ CONSULTING Deutschland
 
Agiles Testen (German)
Agiles Testen (German)Agiles Testen (German)
Agiles Testen (German)
Christian Hassa
 
The new job of qa was ein quality engineer zukünftig können muss
The new job of qa   was ein quality engineer zukünftig können mussThe new job of qa   was ein quality engineer zukünftig können muss
The new job of qa was ein quality engineer zukünftig können muss
raezz
 
Agiles Testen
Agiles TestenAgiles Testen
Agiles Testen
oose
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der ArchitekturdokumentationSteht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
oose
 
Die unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles AnforderungsmanagementDie unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles Anforderungsmanagement
Thomas Moedl
 

Was ist angesagt? (11)

Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
 
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
 
Qz Req Eng Ebert Rudorfer 2011 V3
Qz Req Eng Ebert Rudorfer 2011 V3Qz Req Eng Ebert Rudorfer 2011 V3
Qz Req Eng Ebert Rudorfer 2011 V3
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
 
Agiles Testen (German)
Agiles Testen (German)Agiles Testen (German)
Agiles Testen (German)
 
The new job of qa was ein quality engineer zukünftig können muss
The new job of qa   was ein quality engineer zukünftig können mussThe new job of qa   was ein quality engineer zukünftig können muss
The new job of qa was ein quality engineer zukünftig können muss
 
Agiles Testen
Agiles TestenAgiles Testen
Agiles Testen
 
Mehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements EngineeringMehr Softwarequalität: Requirements Engineering
Mehr Softwarequalität: Requirements Engineering
 
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der ArchitekturdokumentationSteht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
 
Die unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles AnforderungsmanagementDie unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles Anforderungsmanagement
 

Ähnlich wie Mastering architecture, design- and code-quality

IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
Carsten Cordes
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
ChristinaLerch1
 
Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013
superflomo
 
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-UmgebungDas Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
OPITZ CONSULTING Deutschland
 
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
Christian Mücke
 
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
AKJoom
 
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
.NET User Group Rhein-Neckar
 
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo GmbH
 
WUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick WinsWUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick Wins
guest60c1a2
 
eparo – Usability 2.0 (Vortrag OMF 2009 – Rolf Schulte Strathaus)
eparo – Usability 2.0 (Vortrag OMF 2009 – Rolf Schulte Strathaus) eparo – Usability 2.0 (Vortrag OMF 2009 – Rolf Schulte Strathaus)
eparo – Usability 2.0 (Vortrag OMF 2009 – Rolf Schulte Strathaus)
eparo GmbH
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Markus Unterauer
 
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...
Stephan Volmer
 
DevSecOps .pptx
DevSecOps .pptxDevSecOps .pptx
DevSecOps .pptx
ChristianBauer61
 
Software Entwicklung im Team
Software Entwicklung im TeamSoftware Entwicklung im Team
Software Entwicklung im Team
brandts
 
The Best Business Software in Town - Wie agiles Requirements Engineering die ...
The Best Business Software in Town - Wie agiles Requirements Engineering die ...The Best Business Software in Town - Wie agiles Requirements Engineering die ...
The Best Business Software in Town - Wie agiles Requirements Engineering die ...
Christopher Schulz
 
Testgetriebene Softwareentwicklung
Testgetriebene SoftwareentwicklungTestgetriebene Softwareentwicklung
Testgetriebene Softwareentwicklung
jlink
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-Qualitätssicherung
Christian Baranowski
 
Digital Labs & Hubs - ein Erfolgsrezept?
Digital Labs & Hubs - ein Erfolgsrezept?Digital Labs & Hubs - ein Erfolgsrezept?
Digital Labs & Hubs - ein Erfolgsrezept?
Christoph Schmiedinger
 
Clean Coding - Theorie und Praxis Guide.pptx
Clean Coding - Theorie und Praxis Guide.pptxClean Coding - Theorie und Praxis Guide.pptx
Clean Coding - Theorie und Praxis Guide.pptx
kaftanenko
 
Low Budget Usability Testing Webtreff Konstanz Patric Schmid Benutzerzentrale
Low Budget Usability Testing Webtreff Konstanz Patric Schmid BenutzerzentraleLow Budget Usability Testing Webtreff Konstanz Patric Schmid Benutzerzentrale
Low Budget Usability Testing Webtreff Konstanz Patric Schmid Benutzerzentrale
Patric Schmid
 

Ähnlich wie Mastering architecture, design- and code-quality (20)

IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
 
Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013Stay calm & keep shipping - iOS DevCon 2013
Stay calm & keep shipping - iOS DevCon 2013
 
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-UmgebungDas Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
 
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
 
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
 
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
30. Treffen der .NET User Group Rhein-Neckar mit Constantin Klein - „Bekommen...
 
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
 
WUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick WinsWUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick Wins
 
eparo – Usability 2.0 (Vortrag OMF 2009 – Rolf Schulte Strathaus)
eparo – Usability 2.0 (Vortrag OMF 2009 – Rolf Schulte Strathaus) eparo – Usability 2.0 (Vortrag OMF 2009 – Rolf Schulte Strathaus)
eparo – Usability 2.0 (Vortrag OMF 2009 – Rolf Schulte Strathaus)
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
 
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...
 
DevSecOps .pptx
DevSecOps .pptxDevSecOps .pptx
DevSecOps .pptx
 
Software Entwicklung im Team
Software Entwicklung im TeamSoftware Entwicklung im Team
Software Entwicklung im Team
 
The Best Business Software in Town - Wie agiles Requirements Engineering die ...
The Best Business Software in Town - Wie agiles Requirements Engineering die ...The Best Business Software in Town - Wie agiles Requirements Engineering die ...
The Best Business Software in Town - Wie agiles Requirements Engineering die ...
 
Testgetriebene Softwareentwicklung
Testgetriebene SoftwareentwicklungTestgetriebene Softwareentwicklung
Testgetriebene Softwareentwicklung
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-Qualitätssicherung
 
Digital Labs & Hubs - ein Erfolgsrezept?
Digital Labs & Hubs - ein Erfolgsrezept?Digital Labs & Hubs - ein Erfolgsrezept?
Digital Labs & Hubs - ein Erfolgsrezept?
 
Clean Coding - Theorie und Praxis Guide.pptx
Clean Coding - Theorie und Praxis Guide.pptxClean Coding - Theorie und Praxis Guide.pptx
Clean Coding - Theorie und Praxis Guide.pptx
 
Low Budget Usability Testing Webtreff Konstanz Patric Schmid Benutzerzentrale
Low Budget Usability Testing Webtreff Konstanz Patric Schmid BenutzerzentraleLow Budget Usability Testing Webtreff Konstanz Patric Schmid Benutzerzentrale
Low Budget Usability Testing Webtreff Konstanz Patric Schmid Benutzerzentrale
 

Mastering architecture, design- and code-quality

  • 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

Hinweis der Redaktion

  1. © e-movimento
  2. © e-movimento
  3. Djoser-Pyramide (-2690) Cheops-Pyramide (-2570) Kathedrale von Lincoln (1311) Washington Monument (1884) Eiffelturm (1889) Chrysler Building (1930) Empire State Building (1931) World Trade Center 1 (1972) Sears Tower (1974) Petronas Towers (1998) Taipei 101 (2004) Burj Khalifa (2007) © e-movimento
  4. Jon R. Katzenbach, Douglas K. Smith: „Teams: Der Schlüssel zur Hochleistungsorganisation“ © e-movimento
  5. Projektmanagementdokumentation lt. IPMA Testdokumentation lt. … © e-movimento
  6. © e-movimento
  7. [Jones 1996] Applied Software Measurement , Capers Jones, 1996 [Jones 1986] Programming Productivity , Capers Jones, 1986 [Jones 1996] Software Defect-Removal Efficiency , Capers Jones, 1996 [Shull 2002] What We Have Learned About Fighting Defects , Shull et al 2002 [McConnell 2004] Code Complete , Steve McConnell 2004 [Software Metrics 01] http://www.softwaremetrics.com/Articles/defects.htm © e-movimento
  8. [Jones 1996] Applied Software Measurement , Capers Jones, 1996 [Jones 1986] Programming Productivity , Capers Jones, 1986 [Jones 1996] Software Defect-Removal Efficiency , Capers Jones, 1996 [Shull 2002] What We Have Learned About Fighting Defects , Shull et al 2002 [McConnell 2004] Code Complete , Steve McConnell 2004 [Software Metrics 01] http://www.softwaremetrics.com/Articles/defects.htm © e-movimento
  9. [Jones 01] , Capers Jones, 2001 [Humphrey 89] Managing the software process , Watts S. Humphrey, 1989 [Jones 1996] Software Defect-Removal Efficiency , Capers Jones, 1996 [Shull 2002] What We Have Learned About Fighting Defects , Shull et al 2002 [McConnell 2004] Code Complete , Steve McConnell 2004 [Software Metrics 01] http://www.softwaremetrics.com/Articles/defects.htm © e-movimento
  10. © e-movimento
  11. © e-movimento Weitere Kontaktmöglichkeiten: [email_address] Skype: sebastian_dietrich http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich