Team Clean Coding: Gemeinsam besser programmieren iks Thementag Mehr Softwarequalität Ausgewählte Themen 22.05.2014 Autor: Dr. Reik Oberrath Seite 2 / 59
Was ist das Ziel der Softwareentwicklung?
Ein Produkt, das den Auftraggeber zufrieden stellt!
Und einen zuverlässigen, effektiven Herstellungsprozess!
Was ist wichtiger? Das Produkt (Finales Ziel mit Selbstzweck) Der Entwicklungsprozess (Zwischenziel, nur Mittel zum Zweck) Seite 6 / 59
Funktionalität extern Usability Zuverlässigkeit Prüfbarkeit Sicherheit Performanz Installierbarkeit Änderbarkeit Wartbarkeit Testbarkeit Qualität Architektur Architektur Technologie Design Code Technologie Design Code Quelle : http://www.dadalos-d.org/frieden/images/eisberg-modell.jpg Seite 7 / 59 intern
Was ist wichtiger? Das Produkt (Finales Ziel mit Selbstzweck) Produkt und Prozess sind gleich wichtig extern Der Entwicklungsprozess (Zwischenziel, nur Mittel zum Zweck) Qualität Seite 8 / 59 intern
Was beeinflusst den Entwicklungsprozess? Der Faktor Mensch Tools & Technologien Architektur und Implementation
Agenda Einleitung Die Clean-Code-Developer-Bewegung Meinungen zu Clean Code Das Team Clean Coding (TCC) TCC-Rahmenbedingungen Take-Home-Message Seite 10 / 59
Was heißt clean? Def. 1: Clean ist alles, was intuitiv verständlich ist, also (Quellcode-) Dokumente, Datenstrukturen, Konzepte, Regeln, Verfahren... Def. 2: Intuitiv verständlich ist, was mit wenig Spezialwissen in kurzer Zeit richtig verstanden wird. Def. 3: Clean ist alles, was effizient ist, also alles, was die Softwareentwicklung beschleunigt. Seite 11 / 59
Kernaussagen der Clean-Code-Developer-Bewegung Disziplin ( Professionalität ) Ständige Selbstkontrolle ( Bewusstsein ) durch konsequente Anwendung ( gegen widrige Umstände ) des inneren Wertesystems ( Prinzipien ). Wertesystem Programmieralltag www.clean-code-developer.de Das Buch Clean Code ist wert, als allgemeingültiges Wertesystem anerkannt zu werden. Das CCD-Grade-System hilft, das innere Wertesystem aktiv einzusetzen und die mentale CCD-Einstellung zu verinnerlichen. Seite 13 / 59
Praktiken Prinzipien Das - Grade-System: Schwarz Rot Orange Gelb Grün Blau Weiss Don t Repeat Yourself (DRY), Keep it simple, stupid (KISS) Vorsicht vor Optimierungen (VvO) Favour Composition over Inheritance (FCoI) Single Level of Abstraction (SLA) Single Responsibility Principle (SRP) Separation of Concerns (SoC) Interface Segregation Principle Dependency Inversion Principle Liskov Substitution Principle Open Closed Principle Tell, don t ask Law of Demeter www.iks-gmbh.com Principle of Source Code Least Konventionen Astonishment Information Hiding Principle Entwurf und Implementation überlappen nicht Implementation spiegelt Entwurf You Ain t Gonna Need It (YAGNI) Die Pfadfinderregel beachten Root Cause Analysis Ein Versionskontrollsystem einsetzen Einfache Refaktorisierungsmuster anwenden (ER) Täglich reflektieren Issue Tracking Automatisierte Integrationstests Lesen, Lesen, Lesen (LLL) Reviews Automatisierte Unit Tests Mockups (Testattrappen) Code Coverage Analyse Teilnahme an Fachveranstaltungen Komplexe Refaktorisierungen Continuous Integration I Statische Codeanalyse (Metriken) Inversion of Control Container Erfahrung weitergeben Messen von Fehlern Continuous Integration II Iterative Entwicklung Komponentenorientierung Test first
Agenda Einleitung Die Clean-Code-Developer-Bewegung Meinungen zu Clean Code Das Team Clean Coding (TCC) TCC-Rahmenbedingungen Take-Home-Message Seite 15 / 59
www.iks-gmbh.com Clean Code ist gut, aber praxisfern eher etwas für Ästheten! Clean Code ist gut, man kann es aber leicht übertreiben!
www.iks-gmbh.com Ein Organismus verträgt nur ein begrenztes Maß an Schadstoffen. Durch kontinuierliche Arbeit wird dieses Maß klein gehalten.
www.iks-gmbh.com Clean Code ist was für Spießer wichtig ist nur, dass es läuft! Wichtig sind Funktionsfähigkeit, Stabilität, Wartbarkeit und Erweiterbarkeit. Dazu braucht man keinen Clean Code!
Sauberer Code Hohe Testabdeckung Produktionscode Testabdeckung Testcode Schmutz akkumuliert von alleine. Schmutz stellt eine reale Gefahr für die Entwicklung dar. Seite 19 / 59
Unter Zeitdruck wird dann sowieso wieder Quick & Dirty gearbeitet! Seite 20 / 59
Kosten Termine Qualität Kosten Termine Qualität CCD-Professionalität leben und seinen Prinzipien treu bleiben. Technische Schulden bewusst eingehen und bewusst wieder begleichen. Seite 21 / 59
Clean Code kostet zusätzliche Zeit in der Entwicklung! Clean Code spart Zeit in der Wartung!
Kritikalität Langlebigkeit Seite 23 / 59
Agenda Einleitung Die Clean-Code-Developer-Bewegung Meinungen zu Clean Code Das Team Clean Coding (TCC) TCC-Rahmenbedingungen Take-Home-Message Seite 24 / 59
Zusammenhang zwischen CCD und TCC Prinzipien, Praktiken, Selbstkontrolle Teamarbeit, Kommunikation, Teamkontrolle Unterschiede: Es gibt zusätzliche Regeln, die das Teamplay betreffen z.b. 1 -Regel oder Code-Tagging Appell an die Vernunft der Entwickler zu schwach, eine soziale Form von Kontrolle ist nötig Seite 25 / 59
Das Team Clean Coding Warum TCC? Gute Vorsätze schwinden schnell Verrottung Unterschiedliche Meinungen Wildwuchs Mittel gegen die Durchsetzungsstarken (Die Stillen sind nicht automatisch schlechter) Eine soziale, wechselseitige Kontrolle auf Augenhöhe Motivation durch wortlose Anerkennung Seite 26 / 59
Das Team Clean Coding: Übersicht Kontrolle Judikative Konstitution Def. der Legislative Initialisierung Verfass.- schutz Grundgesetz Legislative Optimierung Parlament Executive Anwendung Seite 27 / 59
TCC-Übersicht Initialisierung Judikative Konstitution Def. der Legislative Verfass.- schutz Grundgesetz Legislative Parlament Executive Seite 28 / 59
TCC: Verfassung/Konstitution Notwendiger Basis-Konsens 1.1 ALLE Teammitglieder (inkl. Projektleitung) verpflichten sich, Regeln und Prozesse anzuerkennen, die für ALLE gleichermaßen bindend sind. 1.2 Diese Regeln und Prozesse können bei Bedarf jederzeit angepasst werden. 2 Zuerst wird ein Verfahren zur Entscheidungsfindung festgelegt (Definition der Legislative ). 3 Die Legislative legt einen Satz von Basisregeln fest (das Grundgesetz ). Seite 29 / 59
TCC: Verfassung/Legislative Methoden zur Entscheidungsfindung Vorgabe durch Projektleiter / Chefentwickler / Architekt Mehrheitsbeschluss Minimierung des durchschn. Widerstands Vetoabfrage Konsensrunde Thumb-Voting Konsens bedeutet die Übereinstimmung von Menschen hinsichtlich einer Thematik ohne verdeckten oder offenen Widerspruch. - Wikipedia Seite 30 / 59
TCC: Verfassung/Grundgesetz Basisregeln (Projekt-unspezifische Regeln) 3.1 Wie wollen wir Information festhalten? Dokumentation 3.2 Was bedeutet für uns fertig? Definition Of Done Seite 31 / 59
Ein Anwendungsfall läuft Die guten Anwendungsfälle laufen Fehlerfälle wurden untersucht Alle Anwendungsfälle laufen Unit-Tests Integrationstests Systemtests Automatische Code-Analysen (Metriken) Menschliche Code-Analysen (Review) Seite 32 / 59
TCC: Verfassung/Grundgesetz Projekt-unspezifische Grundregeln 3.1 Wie wollen wir Information festhalten? Dokumentation 3.2 Was bedeutet für uns fertig? Definition Of Done 3.3 Was heißt für uns clean? CCD-Regeln 3.4 Wie gehen wir mit unfertigem Code um? Code Tagging System 3.5 Wie ist unser Umgang mit fremdem Eigentum? Seite 33 / 59
TCC-Übersicht Basiskonsens Initialisierung Judikative Konstitution Def. der Legislative Methode der Entscheidungsfindung Verfass.- schutz Grundgesetz Projektunspezifische Regeln Legislative Parlament Executive Optimierung Anwendung Seite 34 / 59
TCC: Exekutive Programmieralltag (Anforderungen analysieren, implementieren, Qualität sichern, ) CCD- und TCC-Regeln im Bewusstsein halten Seinem Berufsethos auch unter widrigen Umständen treu bleiben Seite 35 / 59
TCC: Parlament/Legislative Forum für Informationsaustausch und Diskussionen sowie Verabschiedung weiterer (Projekt-spezifischer) Regeln Daily Standups (Scrum-ähnlich) Regelmäßige Team-Reviews Retrospektiven Pair-Programming Coding-Notes kommunizieren (z.b. E-Mail an Team-Verteiler) Seite 36 / 59
TCC-Übersicht Kontrolle Basiskonsens Initialisierung Judikative Konstitution Def. der Legislative Methode der Entscheidungsfindung Verfass.- schutz Grundgesetz Projektunspezifische Regeln Projektspezifische Regeln Optimierung Legislative Parlament Diskussionsforum Executive Projektalltag Anwendung Seite 37 / 59
TCC: Verfassungsschutz 4 - Review Am Ende der Entwicklung eines Software-Tasks sucht der Autor nach einem Teammitglied, das als Reviewer dient. Dieser prüft: Funktionelle Korrektheit DoD erfüllt, z.b. Ausreichende Testabdeckung Einhaltung der abgestimmten Clean-Code-Maßnahmen FIXME- / TODO-Einträge (Code Tagging System) Erst nach dem OK des Reviewers gilt der Teil offiziell als FERTIG. Seite 38 / 59
TCC: Judikative Die 1 -Regel Ein Euro wird eingezogen bei Vergehen gegen zuvor abgestimmte Regeln, deren Verstoß von der Legislativen als strafbar gewertet wurde. Beispiele: CI-Build brechen und nach Hause gehen, Tests brechen und sich nicht um deren Behebung bemühen, Backend-Änderungen ohne Client-Anpassung, Domain-Änderungen ohne DB-Skript-Anpassung, etc. Seite 39 / 59
TCC-Übersicht Kontrolle Basiskonsens Initialisierung 1 -Regeln Judikative Konstitution Def. der Legislative Methode der Entscheidungsfindung 4 - Review Verfass.- schutz Grundgesetz Projektunspezifische Regeln Projektspezifische Regeln Optimierung Legislative Parlament Diskussionsforum Executive Projektalltag Anwendung Seite 40 / 59
Agenda Einleitung Die Clean-Code-Developer-Bewegung Meinungen zu Clean Code Das Team Clean Coding (TCC) TCC-Rahmenbedingungen Take-Home-Message Seite 41 / 59
TCC-Rahmenbedingungen Teamstimmung beachten und fördern Haufen Gruppe Team Seite 42 / 59
TCC-Rahmenbedingungen Teamstimmung beachten und fördern Bewusste Teamzusammenstellung Retrospektive-Meetings / gemeinsames Essengehen Bei Bedarf Teamzusammenstellung ändern Organisationsstruktur des Teams ändern Hierarchisch Parlamentarisch Selbstorganisiert Seite 43 / 59
TCC-Rahmenbedingungen Teamstimmung beachten und fördern Zeit für Kommunikation im Team einplanen Tägliche Standup-Meetings Wöchentliche Code-Review-Meetings Monatliche Retrospektive-Meetings Seite 44 / 59
TCC-Rahmenbedingungen Teamstimmung beachten und fördern Zeit für Kommunikation im Team einplanen Fortbildung der Teammitglieder unterstützen Akzeptanz signalisieren und Infrastruktur bereitstellen Seite 45 / 59
Agenda Einleitung Die Clean-Code-Developer-Bewegung Meinungen zu Clean Code Das Team Clean Coding (TCC) TCC-Rahmenbedingungen Take-Home-Message Seite 46 / 59
Rückblick Rückblick Was ist wichtiger? Das Produkt (Finales Ziel mit Selbstzweck) Produkt und Prozess sind gleich wichtig extern Der Entwicklungsprozess (Zwischenziel, nur Mittel zum Zweck) Qualität Rückblick intern Seite 47 / 59 Rückblick
Rückblick Kosten Rückblick Termine Qualität Kosten Termine Qualität CCD-Professionalität leben und seinen Prinzipien treu bleiben. Rückblick Technische Schulden bewusst eingehen und bewusst wieder begleichen. Seite 48 / 59 Rückblick
Rückblick Sauberer Code Hohe Testabdeckung Rückblick Produktionscode Testabdeckung Testcode Rückblick Gegen Schmutz muss regelmäßig gearbeitet werden! Seite 49 / 59 Rückblick
Take-Home-Message Herstellungsprozess und Produkt sind gleich wichtig technische Schulden müssen zurückgezahlt werden! Seite 50 / 59
Praktiken Prinzipien Rückblick Das - Grade-System: Rückblick Schwarz Rot Orange Gelb Grün Blau Weiss Don t Repeat Yourself (DRY), Keep it simple, stupid (KISS) Vorsicht vor Optimierungen (VvO) Favour Composition over Inheritance (FCoI) Single Level of Abstraction (SLA) Single Responsibility Principle (SRP) Separation of Concerns (SoC) Interface Segregation Principle Dependency Inversion Principle Liskov Substitution Principle Open Closed Principle Tell, don t ask Law of Demeter www.iks-gmbh.com Principle of Source Code Least Konventionen Astonishment Information Hiding Principle Entwurf und Implementation überlappen nicht Implementation spiegelt Entwurf You Ain t Gonna Need It (YAGNI) Rückblick Die Pfadfinderregel beachten Root Cause Analysis Ein Versionskontrollsystem einsetzen Einfache Refaktorisierungsmuster anwenden (ER) Täglich reflektieren Issue Tracking Automatisierte Integrationstests Lesen, Lesen, Lesen (LLL) Reviews Automatisierte Unit Tests Mockups (Testattrappen) Code Coverage Analyse Teilnahme an Fachveranstaltungen Komplexe Refaktorisierungen Continuous Integration I Statische Codeanalyse (Metriken) Inversion of Control Container Erfahrung weitergeben Messen von Fehlern Continuous Integration II Iterative Entwicklung Komponentenorientierung Test first Seite 51 / 59 Rückblick
Take-Home-Message Herstellungsprozess und Produkt sind gleich wichtig technische Schulden müssen zurückgezahlt werden! Die CCD-Regeln sind bewährte Mittel zur Steigerung von Qualität und Effizienz Seite 52 / 59
TCC-Übersicht Rückblick Rückblick Kontrolle Basiskonsens Initialisierung 1 -Regeln Judikative Konstitution Def. der Legislative Methode der Entscheidungsfindung 4 - Review Verfass.- schutz Grundgesetz Projektunspezifische Regeln Optimierung Rückblick Projektspezifische Regeln Legislative Parlament Diskussionsforum Executive Projektalltag Anwendung Seite 53 / 59 Rückblick
Rückblick Rückblick Das Team Clean Coding Warum TCC? Gute Vorsätze schwinden schnell Verrottung Unterschiedliche Meinungen Wildwuchs Mittel gegen die Durchsetzungsstarken (Die Stillen sind nicht automatisch schlechter) Wechselseitige Kontrolle auf Augenhöhe Motivation durch wortlose Anerkennung Rückblick Seite 54 / 59 Rückblick
Take-Home-Message Herstellungsprozess und Produkt sind gleich wichtig technische Schulden müssen zurückgezahlt werden! Die CCD-Regeln sind bewährte Mittel zur Steigerung von Qualität und Effizienz TCC fördert die Kommunikation im Team und die konsequente Anwendung der CCD-Regeln Rahmenbedingungen für TCC müssen stimmen Teamstimmung beachten und fördern Zeit für Kommunikation im Team einplanen Fortbildung der Teammitglieder unterstützen Akzeptanz signalisieren und Infrastruktur bereitstellen Seite 55 / 59
Take-Home-Message CCD und TCC führen zu Qualität und Effizienz, benötigen aber Unterstützung aus dem Umfeld! Seite 56 / 59
Weiterführende Literatur Clean Code, Robert C. Martin, Prentice Hall, 2008 The Clean Coder, Robert C. Martin, Prentice Hall, 2011 Clean Coder: Verhaltensregeln für professionelle Programmierer, Robert C. Martin, Addison-Wesley, 2011 The Pragmatic Programmer, Addison-Wesley, 1999 Soft Skills für Softwareentwickler, dpunkt-verlag, 2010 http://www.clean-code-developer.de http://de.wikipedia.org/wiki/clean_code http://www.clean-code.info Seite 57 / 59
Bildernachweise Die in diesem Vortrag verwendeten Bilder stammen von folgenden Quellen: Folie 3: Folie 4: Folie 5: Folie 7,8,9: Folie 11: Folie 12: Folie 16: Folie 28: http://www.flickr.com http://www.flickr.com/photos/23313526@n07/4948442428/sizes/l/in/photostream/ http://www.flickr.com/photos/29747502@n03/2784238062/sizes/l/in/photostream/ http://www.flickr.com/photos/buridansesel/6163446452/sizes/l/in/photostream/ http://officeimg.vo.msecnd.net/en-us/images/mb900443111.jpg http://officeimg.vo.msecnd.net/en-us/images/mb900443251.jpg http://www.dadalos-d.org/frieden/images/eisberg-modell.jpg http://www.hborchert.de/medihumor.htm http://hdfreewallpaper.info/fishy-ubuntu-1920-x-1080.html http://photos.signonsandiego.com/album55/mud02 http://freepostermaker.com/uploads/saved_posters/free-poster-dnxeoi88fg-willies-wash.jpg http://www.flickr.com/photos/oskay/437341603/ Seite 58 / 59
Weitere Bildernachweise 1. Die meisten nicht separat aufgeführten Icons stammen von http://office.microsoft.com/en-us/images und http://office.microsoft.com/de-de/images. 2. Andere nicht aufgeführte Bilder (z.b. auf Folie 17) wurden von den Autoren selbst erstellt. 3. CCD-Logo http://www.clean-code-developer.de 4. Wasserrad http://www.wasserrad-drews.de/ Seite 59 / 59
Fragen?
www.iks-gmbh.com