Download pdf - Mehr Softwarequalität: Team-Cleancoding

Seite 2 / 59 Team Clean Coding: Gemeinsam besser programmieren

Team Clean Coding:

Gemeinsam besser programmieren

iks Thementag

„Mehr Softwarequalität – Ausgewählte Themen“

12.11.2013

Autor:

Dr. Reik Oberrath

Was ist das Ziel der Softwareentwicklung?

Ein Produkt, das

den Auftraggeber

zufrieden stellt!

Und einen zuverlässigen, effektiven Herstellungsprozess!


Das Produkt (Finales Ziel mit

Selbstzweck)

Der Entwicklungs-

prozess (Zwischenziel, nur

Mittel zum Zweck)

Was ist wichtiger?


Architektur

Design Technologie

Code

Architektur

Design Technologie

Code

Funktionalität

Testbarkeit

Wartbarkeit

Usability Zuverlässigkeit

Prüfbarkeit Installierbarkeit

Änderbarkeit

Performanz Sicherheit

extern

intern

Quelle : http://www.dadalos-d.org/frieden/images/eisberg-modell.jpg

Qu

alitä

t



Selbstzweck)

Der Entwicklungs-


Mittel zum Zweck)

Was ist wichtiger?

extern

intern

Produkt und Prozess

sind gleich wichtig

Qu

alitä

t

Der Faktor

„Mensch“

Architektur und

Implementation Tools

&

Technologien

Was beeinflusst den Entwicklungsprozess?


Agenda

Einleitung

Die Clean-Code-Developer-Bewegung

Meinungen zu Clean-Code

Das Team Clean Coding (TCC)

TCC-Rahmenbedingungen

Take-Home-Message


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.

Was heißt clean?

Def. 3: Clean ist alles, was effizient ist, also alles, was

die Softwareentwicklung beschleunigt.


Kernaussagen der

Clean-Code-Developer-Bewegung

Disziplin Ständige Selbstkontrolle („Bewusstsein“)

durch konsequente Anwendung („gegen

widrige Umstände“) des inneren Werte-

systems („Prinzipien“).

Wertesystem Das Buch „Clean Code“ ist wert, als

allgemeingültiges Wertesystem anerkannt

zu werden.

Programmieralltag Das CCD-Grade-System hilft, das innere

Wertesystem aktiv einzusetzen und die

mentale CCD-Einstellung zu verinnerlichen. www.clean-code-developer.de

(„Professionalität“)

www.iks-gmbh.com

Pri

nzip

ien

P

rakti

ken

Continuous

Integration I

Statische

Codeanalyse

(Metriken)

Inversion of

Control Container

Erfahrung

weitergeben

Messen von

Fehlern

Open Closed

Principle

Tell, don´t ask

Law of Demeter

Grün

Continuous

Integration II

Iterative

Entwicklung

Komponenten-

orientierung

Test first

Entwurf und

Implementation

überlappen nicht

Implementa-

tion spiegelt

Entwurf

You Ain´t

Gonna Need It

(YAGNI)

Blau

Automatisierte

Unit Tests

Mockups

(Testattrappen)

Code Coverage

Analyse

Teilnahme an

Fachveranstal-

tungen

Komplexe Re-

faktorisierungen

Issue Tracking

Automatisierte

Integrationstests

Lesen, Lesen,

Lesen (LLL)

Reviews

Die Pfadfinderregel

beachten

Root Cause

Analysis

Ein Versionskon-

trollsystem einsetzen

Einfache Refakto-

risierungsmuster an-

wenden (ER)

Täglich reflektieren

Interface

Segregation

Principle

Dependency

Inversion Principle

Liskov

Substitution

Principle

Principle of

Least

Astonishment

Information

Hiding Principle

Single Level of

Abstraction

(SLA)

Single

Responsibility

Principle (SRP)

Separation of

Concerns (SoC)

Source Code

Konventionen

Don´t Repeat

Yourself (DRY),

Keep it simple,

stupid (KISS)

Vorsicht vor

Optimierungen

(VvO)

Favour

Composition over

Inheritance (FCoI)

Weiss Gelb Orange Rot Schwarz

Pri

nzip

ien

P

rakti

ken

Das - Grade-System:


Agenda

Einleitung





Take-Home-Message

www.iks-gmbh.com

Clean-Code ist gut, man kann es aber leicht übertreiben!

Clean-Code ist gut, aber praxisfern – eher etwas für Ästheten!

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

Wichtig sind Funktionsfähigkeit, Stabilität, Wartbarkeit und Erweiterbarkeit.

Dazu braucht man keinen Clean-Code!

Clean-Code ist was für Spießer – wichtig ist nur, dass es läuft!


Sauberer Code – Hohe Testabdeckung

Produktionscode

Testabdeckung

Testcode

Schmutz akkumuliert von alleine.

Schmutz stellt eine reale Gefahr für die Entwicklung dar.

Seite 20 / 59 Team Clean Coding: Gemeinsam besser programmieren Unter Zeitdruck wird dann sowieso wieder „Quick & Dirty“ gearbeitet!


CCD-Professionalität

leben und seinen Prinzipien

treu bleiben.

Technische Schulden

bewusst eingehen und

bewusst wieder begleichen.

Termine

Termine

Qualität

Qualität

Kosten

Kosten

Clean Code kostet zusätzliche Zeit

in der Entwicklung!

Clean Code spart Zeit

in der Wartung!


Langlebigkeit

Kritikalit

ät


Agenda

Einleitung





Take-Home-Message


Zusammenhang zwischen CCD und TCC

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

Prinzipien,

Praktiken,

Selbstkontrolle

Teamarbeit,

Kommunikation,

Teamkontrolle


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


Das Team Clean Coding: Übersicht

Initialisierung

Anwendung

Optimierung

Kontrolle

Def. der

Legislative

Grund-

gesetz

Konsti-

tution

Executive

Parla-

ment

Legislative

Judikative

Ordnungs-

amt


TC

C-Ü

be

rsic

ht

Initialisierung

Def. der

Legislative

Grund-

gesetz

Executive

Parla-

ment

Legislative

Judikative

Ordnungs-

amt

Konsti-

tution


TCC: „Verfassung/Konstitution“

Notwendiger Basis-Konsens

§1.1 ALLE Teammitglieder (inkl. Projektleitung) verpflichten sich,

Regeln und Prozesse anzuerkennen, die für ALLE gleicher-

maß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“).


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


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


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)


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“?


TC

C-Ü

be

rsic

ht

Initialisierung

Def. der

Legislative

Grund-

gesetz

Executive

Parla-

ment

Legislative

Judikative

Ordnungs-

amt

Konsti-

tution

Optimierung Anwendung

Basiskonsens

Methode der

Entscheidungsfindung

Projekt-

unspezifische

Regeln


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


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)


TC

C-Ü

be

rsic

ht

Initialisierung

Def. der

Legislative

Grund-

gesetz

Executive

Parla-

ment

Legislative

Judikative

Ordnungs-

amt

Konsti-

tution


Basiskonsens

Methode der


Projekt-

unspezifische

Regeln

Kontrolle

Diskussions-

forum

Projektalltag Projekt-

spezifische

Regeln


TCC: „Ordnungsamt“

4 - Review

Am Ende der Entwicklung eines Software-Teils 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.


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.


TC

C-Ü

be

rsic

ht 1€-Regeln

Initialisierung

Def. der

Legislative

Grund-

gesetz

Executive

Parla-

ment

Legislative

Judikative

Ordnungs-

amt

Konsti-

tution


Basiskonsens

Methode der


Projekt-

unspezifische

Regeln

Kontrolle

Diskussions-

forum


spezifische

Regeln

4 -

Review


Agenda

Einleitung





Take-Home-Message



Teamstimmung beachten und fördern

Haufen Gruppe Team




Bewusste Teamzusammenstellung

Retrospektive-Meetings / gemeinsames Essengehen

Bei Bedarf Teamzusammenstellung ändern

Organisationsstruktur des Teams ändern

• Hierarchisch

• Parlamentarisch

• Selbstorganisiert




Zeit für Kommunikation im Team einplanen

Tägliche Standup-Meetings

Wöchentliche Code-Review-Meetings

Monatliche Retrospektive-Meetings





Fortbildung der Teammitglieder unterstützen

Akzeptanz signalisieren und Infrastruktur bereitstellen


Agenda

Einleitung





Take-Home-Message



Selbstzweck)

Der Entwicklungs-


Mittel zum Zweck)

Was ist wichtiger?

extern

intern

Produkt und Prozess

sind gleich wichtig

Rückblick

Rückblick

Rückblick

Rückblick

Qu

alitä

t


CCD-Professionalität

leben und seinen Prinzipien

treu bleiben.

Technische Schulden

bewusst eingehen und

bewusst wieder begleichen.

Termine

Termine

Qualität

Qualität

Kosten

Kosten

Rückblick

Rückblick

Rückblick

Rückblick

Seite 49 / 59 Team Clean Coding: Gemeinsam besser programmieren Gegen Schmutz muss regelmäßig gearbeitet werden!

Sauberer Code – Hohe Testabdeckung

Produktionscode

Testabdeckung

Testcode

Rückblick

Rückblick

Rückblick

Rückblick


Take-Home-Message

Herstellungsprozess und Produkt sind gleich wichtig –

technische Schulden müssen zurückgezahlt werden!


www.iks-gmbh.com

Pri

nzip

ien

P

rakti

ken

Continuous

Integration I

Statische

Codeanalyse

(Metriken)

Inversion of

Control Container

Erfahrung

weitergeben

Messen von

Fehlern

Open Closed

Principle

Tell, don´t ask

Law of Demeter

Grün

Continuous

Integration II

Iterative

Entwicklung

Komponenten-

orientierung

Test first

Entwurf und

Implementation

überlappen nicht

Implementa-

tion spiegelt

Entwurf

You Ain´t

Gonna Need It

(YAGNI)

Blau

Automatisierte

Unit Tests

Mockups

(Testattrappen)

Code Coverage

Analyse

Teilnahme an

Fachveranstal-

tungen

Komplexe Re-

faktorisierungen

Issue Tracking

Automatisierte

Integrationstests

Lesen, Lesen,

Lesen (LLL)

Reviews

Die Pfadfinderregel

beachten

Root Cause

Analysis

Ein Versionskon-

trollsystem einsetzen

Einfache Refakto-

risierungsmuster an-

wenden (ER)

Täglich reflektieren

Interface

Segregation

Principle

Dependency

Inversion Principle

Liskov

Substitution

Principle

Principle of

Least

Astonishment

Information

Hiding Principle

Single Level of

Abstraction

(SLA)

Single

Responsibility

Principle (SRP)

Separation of

Concerns (SoC)

Source Code

Konventionen

Don´t Repeat

Yourself (DRY),

Keep it simple,

stupid (KISS)

Vorsicht vor

Optimierungen

(VvO)

Favour

Composition over

Inheritance (FCoI)

Weiss Gelb Orange Rot Schwarz

Pri

nzip

ien

P

rakti

ken

Das - Grade-System:

Rückblick

Rückblick

Rückblick

Rückblick


Take-Home-Message



Die CCD-Regeln sind bewährte Mittel zur Steigerung von

Qualität und Effizienz


TC

C-Ü

be

rsic

ht 1€-Regeln

Initialisierung

Def. der

Legislative

Grund-

gesetz

Executive

Parla-

ment

Legislative

Judikative

Ordnungs-

amt

Konsti-

tution


Basiskonsens

Methode der


Projekt-

unspezifische

Regeln

Kontrolle

Diskussions-

forum


spezifische

Regeln

4 -

Review

Rückblick 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

Rückblick

Rückblick

Rückblick


Take-Home-Message



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



Fortbildung der Teammitglieder unterstützen

Akzeptanz signalisieren und Infrastruktur bereitstellen


Take-Home-Message

CCD und TCC führen zu Qualität und Effizienz,

benötigen aber Unterstützung aus dem Umfeld!


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

http://www.clean-code-developer.de/





http://de.wikipedia.org/wiki/Clean_Code

http://www.clean-code.info/





Bildernachweise

Die in diesem Vortrag verwendeten Bilder stammen von folgenden Quellen:

Folie 3: http://www.flickr.com

Folie 4: http://www.flickr.com/photos/23313526@N07/4948442428/sizes/l/in/photostream/

http://www.flickr.com/photos/29747502@N03/2784238062/sizes/l/in/photostream/

Folie 5: http://www.flickr.com/photos/buridansesel/6163446452/sizes/l/in/photostream/

Folie 7,8,9: 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

Folie 11: http://www.hborchert.de/medihumor.htm

http://hdfreewallpaper.info/fishy-ubuntu-1920-x-1080.html

Folie 12: http://photos.signonsandiego.com/album55/mud02

Folie 16: http://freepostermaker.com/uploads/saved_posters/free-poster-dnxeoi88fg-WILLIES-WASH.jpg

Folie 28: http://www.flickr.com/photos/oskay/437341603/

http://www.flickr.com/



http://www.rottenplaces.de/



































http://freepostermaker.com/uploads/saved_posters/free-poster-dnxeoi88fg-WILLIES-WASH.jpg










http://www.flickr.com/photos/oskay/437341603/



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/




http://office.microsoft.com/de-de/images








http://www.wasserrad-drews.de/





Fragen?

www.iks-gmbh.com