tech talk: wozu clean code?

Clean Code -‐ wozu eigentlich?

Dienstag, 14. Januar 14

Wer sind wir? 2

Me = Lorenz

Dozent Echtzeit-‐ & Prozess-‐EDV

So>ware-‐Entwickler

Koordinator So>wareentwicklung

Teamleiter

Wer bin ich? 3

Scrum-‐MasterProduct-‐Owner

ich brauche hier ein großes Loch

Clean Code -‐ wozu eigentlich? 4

Clean Code -‐ wozu eigentlich? 5

Anforderungen an ein Produkt 6

FunkGon

FunkGon Non FuncGonal Requirements

FunkGon Non Funcitonal Requrements

InvesGGonssicherheit

SE 100%Dienstag, 14. Januar 14

SE 100% SE 25%Dienstag, 14. Januar 14

SE 100% SE 25%Clean CodeDienstag, 14. Januar 14

Inves==onssicherheit 11

Erhalt des Status Quo

prävenGve Wartung

InvesGGonssicherheit ist ein

ökonomischer ImperaGv

Inves=onssicherheit bei So?ware 13

Wartung? Status Quo?

Weiterentwicklung!

prävenGv?

Weiterentwicklung!

prävenGv?

reakGv!

Inhalt : unbekannt!

Weiterentwicklung!

prävenGv?

reakGv!

Inhalt : unbekannt!

Zeitpunkt: unbekannt!

Weiterentwicklung!

prävenGv?

reakGv!

Inhalt : unbekannt!

Zeitpunkt: unbekannt!

Weiterentwicklung!

prävenGv?

reakGv!

Schnell soll‘s gehen, kosten darf‘s nix.

Produk=vität 14

Produk=vität 15

Produk=vität 16

Produk=vität 17

Produk=vität 18

jedes Feature ist mit dem selben Aufwand implemenGerbar, als wäre es das erste Feature gewesen.

Evolvierbarkeit 19

Evolvierbarkeit, Wandelbarkeit 20

jedes Feature ist implemenGerbar, weil möglichst keine Entscheidung irreversibel umgesetzt wird.

die So>ware tut das, was man von ihr erwartet.

Korrektheit 21

Mehrfach tägliches Refactoring sorgt für steGge Verbesserung der So>ware.

Kon=nuierliche Verbesserung 22

leichter verständlich

schneller korrekt

Produk=onseffizienz 23

einfacher angepasst

leichter verständlichleichter verständlichleichter verständlichleichter verständlich

einfacher angepassteinfacher angepassteinfacher angepasst

schneller korrektschneller korrektschneller korrekt

einfacher angepasst

leichter verständlichleichter verständlichleichter verständlichleichter verständlichleichter verständlich

Kosten? 24

Tests + Refactoring

Kosten? 24

Infrastruktur

Tests + Refactoring

Kosten? 24

Infrastruktur

Tests + Refactoring

Weiterbildung

Kosten? 24

Infrastruktur

Tests + Refactoring

Weiterbildung

Kosten? 24

Einarbeitung

Infrastruktur

Tests + Refactoring

Weiterbildung

Kosten? 24

Einarbeitung

Aufwand

Infrastruktur

Tests + Refactoring

Weiterbildung

Kosten? 24

Einarbeitung

Aufwand

Infrastruktur

Tests + Refactoring

Weiterbildung

Kosten? 24

Schätzungen

Evolvierbarkeit, Wandelbarkeit, Korrektheit, ProdukGonseffizienz und konGnuierliche Verbesserung sichern.

Was ist Clean Code? 25

Handwerk

Mindset

AutomaGsierung

Prinzipien

Clean Code 29

Keep It Straight and Simple

Clean Code Prinzipien -‐ KISS 30

Don‘t Repeat Yourself

Clean Code Prinzipien -‐ DRY 31

You Aren‘t Going to Need It

Clean Code Prinzipien -‐ YAGNI 32

Principle of Least Astonishment

Clean Code Prinzipien -‐ PLA 33

SRP, OCP, LSP, ISP, DIP

Clean Code Prinzipien -‐ SOLID 34

Single Responsible Principle (SRP)

“There should never be more than one reason for a class to change.”

Open Closed Principle (OCP)

Offen für Erweiterung

Geschlossen für Veränderung

Liskov SubsGtuGon Principle (LSP)

Class Rectangle

Class Square

Class Rectangle

Class Square

Class Rectangle

Class Square

Interface SegregaGon Principle (ISP)

Dependency Inversion Principle (DIP)

PrakGken

Clean Code 40

Clean Code -‐ Prak=ken

Test FirstUnit-‐TestsApplicaGon-‐Tests

ImplementCode-‐Style

RefactorSOLID? Style?

Clean Code -‐ Prak=ken -‐ Style 45

Clean Code -‐ Prak=ken -‐ Style

z.B. Kurze Klassen & Methoden

z.B. Kurze Klassen & Methodenz.B. eindeuGge und sprechende Namen

z.B. Kurze Klassen & Methodenz.B. eindeuGge und sprechende Namenz.B. einheitliche FormaGerung

z.B. Kurze Klassen & Methodenz.B. eindeuGge und sprechende Namenz.B. einheitliche FormaGerungz.B. vermeiden von Seiteneffekten in FunkGonen

z.B. Kurze Klassen & Methodenz.B. eindeuGge und sprechende Namenz.B. einheitliche FormaGerungz.B. vermeiden von Seiteneffekten in FunkGonenz.B. Anzahl der Argumente in FunkGonen

z.B. Kurze Klassen & Methodenz.B. eindeuGge und sprechende Namenz.B. einheitliche FormaGerungz.B. vermeiden von Seiteneffekten in FunkGonenz.B. Anzahl der Argumente in FunkGonen..... und viele, viele mehr.

z.B. Kurze Klassen & Methodenz.B. eindeuGge und sprechende Namenz.B. einheitliche FormaGerungz.B. vermeiden von Seiteneffekten in FunkGonenz.B. Anzahl der Argumente in FunkGonen..... und viele, viele mehr.Sorry.

Namen sind mehr als Schall und Rauch

* nutze Namen, um deine Absicht zu benennen* nutze eindeuGge Namen* nutze Rollen im Namen, wenn Design-‐Panerns involviert sind. (addressObserver)* meide Namen, die den Leser auf eine falsche Fährte führen* meide sehr ähnliche Namen* meide Rauschen in Namen (Info,Data,Object,the,a,..)* nutze aussprechbare Namen* nutze Namen, nach denen sich suchen lässt* meide Typ-‐ oder Sichtbarkeits-‐Codierung (miDaysLe>)

Namen sind mehr als Schall und Rauch

* nutze SubstanGve für Klassen* nutze Verben für Methoden* meide Slang oder Witzige Namen * wähle einen Namen für ein Konzept und bleibe dabei (lade, lese, hole, was wird hier verwendet?)* vergebe genau einen Namen für eine Idee** meide das Erschaffen von Teekesselchen (Homonyme)** meide das vergeben mehrer Namen für die selbe Idee* nutze Namen aus der Problem-‐Domäne, wenn es keinen technischen Begriff gibt (s.o. Panern-‐Rollen)

Version Control System

Issue TrackingFeatures und Bugs

ConGnuous IntegraGonVoll automaGsierter Build, Deploy und Test-‐ZyklusErfassung von Kennzahlen (KPI‘s)Visualisierung von Ergebnissen

LernenLiteratur, YoutubePair Programming

TrainierenCoding DojosPair Programming

ReflekGerenCoding DojosPair Programming

Clean Code -‐ Wie anfangen? 50

Regeln zu Entwurf und Coding lernen

Clean Code einführen 51

Version Control System: z.B. GIT

Issue Tracking -‐ z.B. Jira

ConGnuous IntegraGon -‐ z.B. Jenkins

Zusammenarbeit im Team: Regeln definieren

Messwerte erfassen -‐ KPI‘s

Software z.B.SonarEmmaFindbugsCheckstyle

Tests sind grün

offene Tickets

Tests sind grün

Testabdeckung

offene Tickets

Tests sind grün

Code-‐Format

Testabdeckung

offene Tickets

Tests sind grün

VerdächGger Code

Code-‐Format

Testabdeckung

offene Tickets

Tests sind grün

CyclomaGc Complexity

VerdächGger Code

Code-‐Format

Testabdeckung

offene Tickets

Tests sind grün

Technical Debt

CyclomaGc Complexity

VerdächGger Code

Code-‐Format

Testabdeckung

offene Tickets

Tests sind grün

Bewertung Trennen

Team Monitor

Softwarewalldee auf Github

Play & Scala :-)

Clean Code 59

Literatur 60

Literatur 61

Literatur 62

www.clean-‐code-‐developer.de

Literatur 63

Literatur 64

Literatur 65

Literatur 66

Literatur 67

Lorenz HahnKoordinator So?ware Entwicklung

Blücherstr. 2210961 Berlin

fon +49 (0)30-‐609 85 71 91mobil +49 (0)179-‐527 76 83

lorenz.hahn@leanovate.de

Xing: hnp://www.xing.com/profiles/Lorenz_Hahn2Linkedin: hnp://de.linkedin.com/in/lorenzhahn

KonGnuierliche Weiterentwicklung der Architektur

Inkrementeller Entwurf 69

Klassisch: Schicht für Schicht mit SchninstellendefiniGon

Inkrementell

Hierbei muss exisGerender Code angepasst werden

=> Refactoring!Dienstag, 14. Januar 14

tech talk: wozu clean code?

Technology

wozu brauchen sie resilienz? - ofpg

social web - und wozu?

wozu wikis?

berlin. wozu reist man? man reist, um …zu. wozu reist man?...

sozak - wozu soziale netzwerke

wozu mikrocontroller?

freiheit wozu fertig-home-page

die videoakademie - wozu und wie

wozu brauche ich ein ipad? - admincamp 2017 -...

wozu ist die schule da?

männersolidarität, wozu?

tech talk buscapé - clean code

wozu brauchen wir unser herz? · script - wozu brauchen wir...

gws - wozu soziale netzwerke

clean water talk draft2

heidegger - wozu dichter

wozu braucht man eigentlich flexionsmorphologie?

wozu soziale netzwerke

finanztransaktionssteuer. 2 wozu finanztransaktionssteuer?

wozu mathematik? gedanken zum mathematikunterricht