• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Mastering architecture, design- and code-quality
 

Mastering architecture, design- and code-quality

on

  • 532 views

"Unkonventionelle" Ideen zur dramatischen Steigerung der Produktivität von Softwareentwicklungsprojekten. ...

"Unkonventionelle" Ideen zur dramatischen Steigerung der Produktivität von Softwareentwicklungsprojekten.
Wieviel Produktivität bringt mir hohe Qualität? Wie die Qualität steigern? Wie die Qualität sichern? Wie Fehler von vornherein vermeiden? Vorstellung einiger unkonventioneller Ansätze wie: Besseres Verständnis durch weniger Dokumentation, bessere Qualität durch weniger Tests, schnellere Entwicklung durch mehr broken Builds

Statistics

Views

Total Views
532
Views on SlideShare
532
Embed Views
0

Actions

Likes
0
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • © e-movimento
  • © e-movimento
  • 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
  • Jon R. Katzenbach, Douglas K. Smith: „Teams: Der Schlüssel zur Hochleistungsorganisation“ © e-movimento
  • Projektmanagementdokumentation lt. IPMA Testdokumentation lt. … © e-movimento
  • © e-movimento
  • [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
  • [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
  • [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
  • © e-movimento
  • © e-movimento Weitere Kontaktmöglichkeiten: [email_address] Skype: sebastian_dietrich http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich

Mastering architecture, design- and code-quality Mastering architecture, design- and code-quality Presentation Transcript

  • e-movimento Software Design & Beratung GmbH1030 Wien ● Marxergasse 7/26 ► www.e-movimento.comMastering Architecture-, Design- andCode-QualityUnkonventionelle Ansätze zurProduktivitä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 hohetechnische Qualität in derSoftwareentwicklung? Wieviel Zeit bringt hohetechnische Qualität in derWartungsphase? Antwort: Die Frage ist falsch: Wartung beginnt mit der Analyse Technische Qualität spart (auchwä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%AnalyseDesignCodierungTestenWartung
  • 7%67%13%5%8%AnalyseDesignCodierungTestenWartung7%13%5%6%53%16%AnalyseDesignCodierungTestenWartungErsparnisKosten schlechter technischer Qualität= „Technische Schuld“ Technische Schuld =„Zusätzlicher Aufwand, den man fürÄnderungen und Erweiterungen anschlecht geschriebener Software imVergleich zu gut geschriebener Softwareeinplanen 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 SchuldWarum 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 Dietrich5Hochsprung, Olympische Spiele 1928„moreofthesame“„unkonventionell“
  • Unkonventionelle AnsätzeIn der Architektur► www.e-movimento.com, Sebastian Dietrich6SteinBetonfundamentEisen StahlStahlbetonIndustrielle 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 Dietrich9Robert C. Martin:„Demanding Professionalismin Software Development“http://www.youtube.com/watch?v=p0O1VVqRSK0
  • „Arbeite professionell“Konsequenzen für professionelle Entwickler1. Frage nicht, tue es! Jesuitenprinzip nach Dave Burns:„Um Verzeihung bitten ist einfacher,als um Erlaubnis zu fragen“ Ein Professionist fragt nicht, ob erprofessionell arbeiten darf!2. Ignoriere diesbezüglich Projektleiter! Projektleiter sind Projektleiter & keineNachhilfelehrer Einmischung in Arbeitsweise =Micromanagement = Antithese zuProjektleitung3. Ignoriere diesbezüglich Kunden! Kunden sind nicht für das „wie“ verantwortlich► www.e-movimento.com, Sebastian Dietrich10CCD ArmbänderKonsequenz genug?
  •  Typische Projektdokumente: Warum dokumentieren wir?Reflexion, Kommunikation, AbsicherungDokumentationWarum dokumentieren wir?► www.e-movimento.com, Sebastian Dietrich11LastenheftPflichtenheftFunktionale SpezifikationNicht-Funktionale SpezifikationUsecasesStoriesObjektmodelleProjektauftragProjektplanungProjektumweltanalyseProjektrisikoanalsyeProjektfortschrittsberichtProjekttagebuchProjektstrukturplanUML-DiagrammeGlossarSchnittstellendefinitionArchitekturbeschreibungDatenbankmodellCode-KommentareJavadocToDos, FIXMEs, XXXTasksCode-ReviewsCheckIn KommentareSchnittstellenbeschreibungenTestpläneTestdesign-SpezifikationTestfälleTestlogTestabschlussberichteBug-ReportsFeature-RequestsBenutzerhandbücherAnwender-TutorialsAbnahmeprotokolleInstallationshandbuchBetriebshandbuchProjektabschlussberichtStundenlistenProjektrollendefinitionProjektzieldefinitionArbeitspaketspezifikationTo-Do-ListenMeetingprotokolleMeetingagendenProjektfunktionendiagramm
  • DokumentationNachteile 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 ReflectionObject 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ürsReflektieren, 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, kurzeMethoden, 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
  • TestenWarum testen wir? Warum testen wir? Warum schreiben wir Unit-Test? Warum schreiben wirIntegrationstests? 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 Testkosten?► www.e-movimento.com, Sebastian Dietrich16PerformancetestsSecuritytestsPenetrationtestsIntegrationstestsSystemtestsLoadtestsAbnahmetestsUsablity TestUnit-TestsLasttestsRegressiontestsFehlertestsSchnittstellentestsInstallationstestsCrashtestsSmoketestsStresstests
  • SystemtestKosten – Nutzen RechnungKosten NutzenSystemtestaufwand:~ 1 PT / TestfallSystemtest findet~ 1 Fehler / TestfallFehlerbehebungsaufwand:~ 1PT / Fehler(10x wie während Entwicklung)Je behobener Fehler:0,5 – 0,8 neue (unentdeckte)Fehler80 – 150%der EntwicklungskostenSystemtest findetmax. 25 – 55% der Fehler Systemtest:Teststufe, bei der das gesamte Systemgegen die gesamten Anforderungen getestet wird.► www.e-movimento.com, Sebastian Dietrich17[Jones 86], [Jones 96a], [Jones 96b], [Shull 02], [McConnell 04]
  • UnittestKosten – Nutzen RechnungKosten NutzenUnit-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 findetmax. 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]
  • UnittestsWarum 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) undReihenfolge 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 aufdas absolut notwendigste Wie fachliche Fehler verhindern? Behavior Driven Development:Analyse mittels Tests Keine Systemtests undAbnahmetests mehr nötig Entwicklung (& TDD) wesentlicheinfacher & weniger Aufwand► www.e-movimento.com, Sebastian Dietrich20Moskitonetz –Verhindert Bugs
  • „Teste nichts – verhindere Fehler“Konsequenzen für Entwickler Erkenntnis: Testen ist sauteuer und bringt wenig Es gibt bessere & günstiger Möglichkeiten umFehler 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 IntegrationWarum 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 technischeQualitä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 dietechnische 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 Dietrich23PMDCPDCheckstyle SonargraphSotographSimianJDependNDependMackerFindBugsLintCppCheckFXCopAxivionNCSSCMTUCDetectorCRAPSonar Build Breaker Plugin
  • ► www.e-movimento.com, Sebastian Dietrich24Vielen Dank für Ihre Aufmerksamkeit!Q&A[Sebastian Dietrich]Sebastian.Dietrich@e-movimento.comhttp://managing-java.blogspot.com