tech talk: wozu clean code?
DESCRIPTION
Wozu brauche ich Clean Code, was kostet Clean Code, was ist Clean Code und wenn ich's haben will, wie führe ich Clean Code ein? Slides des Tech Talk vom 13.01.2014 bei Leanovate von Lorenz HahnTRANSCRIPT
Clean Code -‐ wozu eigentlich?
Dienstag, 14. Januar 14
Wer sind wir? 2
Dienstag, 14. Januar 14
Me = Lorenz
Dozent Echtzeit-‐ & Prozess-‐EDV
So>ware-‐Entwickler
Koordinator So>wareentwicklung
Teamleiter
Wer bin ich? 3
Scrum-‐MasterProduct-‐Owner
Dienstag, 14. Januar 14
ich brauche hier ein großes Loch
Clean Code -‐ wozu eigentlich? 4
Dienstag, 14. Januar 14
Clean Code -‐ wozu eigentlich? 5
Dienstag, 14. Januar 14
Anforderungen an ein Produkt 6
Dienstag, 14. Januar 14
Anforderungen an ein Produkt 7
FunkGon
Dienstag, 14. Januar 14
Anforderungen an ein Produkt 8
FunkGon Non FuncGonal Requirements
Dienstag, 14. Januar 14
Anforderungen an ein Produkt 9
FunkGon Non FuncGonal Requirements
Dienstag, 14. Januar 14
Anforderungen an ein Produkt 10
FunkGon Non Funcitonal Requrements
InvesGGonssicherheit
Dienstag, 14. Januar 14
Anforderungen an ein Produkt 10
FunkGon Non Funcitonal Requrements
InvesGGonssicherheit
SE 100%Dienstag, 14. Januar 14
Anforderungen an ein Produkt 10
FunkGon Non Funcitonal Requrements
InvesGGonssicherheit
SE 100% SE 25%Dienstag, 14. Januar 14
Anforderungen an ein Produkt 10
FunkGon Non Funcitonal Requrements
InvesGGonssicherheit
SE 100% SE 25%Clean CodeDienstag, 14. Januar 14
Inves==onssicherheit 11
Dienstag, 14. Januar 14
Erhalt des Status Quo
Inves==onssicherheit 11
Dienstag, 14. Januar 14
Erhalt des Status Quo
prävenGve Wartung
Inves==onssicherheit 11
Dienstag, 14. Januar 14
Inves==onssicherheit 12
InvesGGonssicherheit ist ein
ökonomischer ImperaGv
Dienstag, 14. Januar 14
Inves=onssicherheit bei So?ware 13
Dienstag, 14. Januar 14
Wartung? Status Quo?
Inves=onssicherheit bei So?ware 13
Dienstag, 14. Januar 14
Weiterentwicklung!
Wartung? Status Quo?
Inves=onssicherheit bei So?ware 13
Dienstag, 14. Januar 14
Weiterentwicklung!
Wartung? Status Quo?
prävenGv?
Inves=onssicherheit bei So?ware 13
Dienstag, 14. Januar 14
Weiterentwicklung!
Wartung? Status Quo?
prävenGv?
Inves=onssicherheit bei So?ware 13
reakGv!
Dienstag, 14. Januar 14
Inhalt : unbekannt!
Weiterentwicklung!
Wartung? Status Quo?
prävenGv?
Inves=onssicherheit bei So?ware 13
reakGv!
Dienstag, 14. Januar 14
Inhalt : unbekannt!
Zeitpunkt: unbekannt!
Weiterentwicklung!
Wartung? Status Quo?
prävenGv?
Inves=onssicherheit bei So?ware 13
reakGv!
Dienstag, 14. Januar 14
Inhalt : unbekannt!
Zeitpunkt: unbekannt!
Weiterentwicklung!
Wartung? Status Quo?
prävenGv?
Inves=onssicherheit bei So?ware 13
reakGv!
Schnell soll‘s gehen, kosten darf‘s nix.
Dienstag, 14. Januar 14
Produk=vität 14
Dienstag, 14. Januar 14
Produk=vität 15
Dienstag, 14. Januar 14
Produk=vität 16
Dienstag, 14. Januar 14
Produk=vität 17
Dienstag, 14. Januar 14
Produk=vität 18
Dienstag, 14. Januar 14
jedes Feature ist mit dem selben Aufwand implemenGerbar, als wäre es das erste Feature gewesen.
Evolvierbarkeit 19
Dienstag, 14. Januar 14
Evolvierbarkeit, Wandelbarkeit 20
jedes Feature ist implemenGerbar, weil möglichst keine Entscheidung irreversibel umgesetzt wird.
Dienstag, 14. Januar 14
die So>ware tut das, was man von ihr erwartet.
Korrektheit 21
Dienstag, 14. Januar 14
Mehrfach tägliches Refactoring sorgt für steGge Verbesserung der So>ware.
Kon=nuierliche Verbesserung 22
Dienstag, 14. Januar 14
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
Dienstag, 14. Januar 14
Kosten? 24
Dienstag, 14. Januar 14
Tests + Refactoring
Kosten? 24
Dienstag, 14. Januar 14
Infrastruktur
Tests + Refactoring
Kosten? 24
Dienstag, 14. Januar 14
Infrastruktur
Tests + Refactoring
Weiterbildung
Kosten? 24
Dienstag, 14. Januar 14
Bugs
Infrastruktur
Tests + Refactoring
Weiterbildung
Kosten? 24
Dienstag, 14. Januar 14
Einarbeitung
Bugs
Infrastruktur
Tests + Refactoring
Weiterbildung
Kosten? 24
Dienstag, 14. Januar 14
Einarbeitung
Bugs
Aufwand
Infrastruktur
Tests + Refactoring
Weiterbildung
Kosten? 24
Dienstag, 14. Januar 14
Einarbeitung
Bugs
Aufwand
Infrastruktur
Tests + Refactoring
Weiterbildung
Kosten? 24
Schätzungen
Dienstag, 14. Januar 14
Evolvierbarkeit, Wandelbarkeit, Korrektheit, ProdukGonseffizienz und konGnuierliche Verbesserung sichern.
Was ist Clean Code? 25
Dienstag, 14. Januar 14
Handwerk
Was ist Clean Code? 26
Dienstag, 14. Januar 14
Mindset
Was ist Clean Code? 27
Dienstag, 14. Januar 14
AutomaGsierung
Was ist Clean Code? 28
Dienstag, 14. Januar 14
Prinzipien
Clean Code 29
Dienstag, 14. Januar 14
Keep It Straight and Simple
Clean Code Prinzipien -‐ KISS 30
Dienstag, 14. Januar 14
Don‘t Repeat Yourself
Clean Code Prinzipien -‐ DRY 31
Dienstag, 14. Januar 14
You Aren‘t Going to Need It
Clean Code Prinzipien -‐ YAGNI 32
Dienstag, 14. Januar 14
Principle of Least Astonishment
Clean Code Prinzipien -‐ PLA 33
Dienstag, 14. Januar 14
SRP, OCP, LSP, ISP, DIP
Clean Code Prinzipien -‐ SOLID 34
Dienstag, 14. Januar 14
Single Responsible Principle (SRP)
Clean Code Prinzipien -‐ SOLID 35
“There should never be more than one reason for a class to change.”
Dienstag, 14. Januar 14
Open Closed Principle (OCP)
Clean Code Prinzipien -‐ SOLID 36
Dienstag, 14. Januar 14
Open Closed Principle (OCP)
Offen für Erweiterung
Clean Code Prinzipien -‐ SOLID 36
Dienstag, 14. Januar 14
Open Closed Principle (OCP)
Offen für Erweiterung
Geschlossen für Veränderung
Clean Code Prinzipien -‐ SOLID 36
Dienstag, 14. Januar 14
Liskov SubsGtuGon Principle (LSP)
Clean Code Prinzipien -‐ SOLID 37
Class Rectangle
Class Square
Dienstag, 14. Januar 14
Liskov SubsGtuGon Principle (LSP)
Clean Code Prinzipien -‐ SOLID 37
Class Rectangle
Class Square
Dienstag, 14. Januar 14
Liskov SubsGtuGon Principle (LSP)
Clean Code Prinzipien -‐ SOLID 37
Class Rectangle
Class Square
Dienstag, 14. Januar 14
Interface SegregaGon Principle (ISP)
Clean Code Prinzipien -‐ SOLID 38
Dienstag, 14. Januar 14
Dependency Inversion Principle (DIP)
Clean Code Prinzipien -‐ SOLID 39
Dienstag, 14. Januar 14
Dependency Inversion Principle (DIP)
Clean Code Prinzipien -‐ SOLID 39
Dienstag, 14. Januar 14
Dependency Inversion Principle (DIP)
Clean Code Prinzipien -‐ SOLID 39
Dienstag, 14. Januar 14
Dependency Inversion Principle (DIP)
Clean Code Prinzipien -‐ SOLID 39
Dienstag, 14. Januar 14
Dependency Inversion Principle (DIP)
Clean Code Prinzipien -‐ SOLID 39
Dienstag, 14. Januar 14
Dependency Inversion Principle (DIP)
Clean Code Prinzipien -‐ SOLID 39
Dienstag, 14. Januar 14
PrakGken
Clean Code 40
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
Test FirstUnit-‐TestsApplicaGon-‐Tests
41
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
Test FirstUnit-‐TestsApplicaGon-‐Tests
42
ImplementCode-‐Style
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
Test FirstUnit-‐TestsApplicaGon-‐Tests
43
RefactorSOLID? Style?
ImplementCode-‐Style
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
Test FirstUnit-‐TestsApplicaGon-‐Tests
44
RefactorSOLID? Style?
ImplementCode-‐Style
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken -‐ Style 45
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken -‐ Style
z.B. Kurze Klassen & Methoden
45
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken -‐ Style
z.B. Kurze Klassen & Methodenz.B. eindeuGge und sprechende Namen
45
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken -‐ Style
z.B. Kurze Klassen & Methodenz.B. eindeuGge und sprechende Namenz.B. einheitliche FormaGerung
45
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken -‐ Style
z.B. Kurze Klassen & Methodenz.B. eindeuGge und sprechende Namenz.B. einheitliche FormaGerungz.B. vermeiden von Seiteneffekten in FunkGonen
45
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken -‐ Style
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
45
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken -‐ Style
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.
45
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken -‐ Style
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.
45
Dienstag, 14. Januar 14
Namen sind mehr als Schall und Rauch
Clean Code -‐ Prak=ken -‐ Style 46
* 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>)
Dienstag, 14. Januar 14
Namen sind mehr als Schall und Rauch
Clean Code -‐ Prak=ken -‐ Style 47
* 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)
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
Version Control System
48
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
Version Control System
48
Issue TrackingFeatures und Bugs
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
Version Control System
48
Issue TrackingFeatures und Bugs
ConGnuous IntegraGonVoll automaGsierter Build, Deploy und Test-‐ZyklusErfassung von Kennzahlen (KPI‘s)Visualisierung von Ergebnissen
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
LernenLiteratur, YoutubePair Programming
49
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
LernenLiteratur, YoutubePair Programming
49
TrainierenCoding DojosPair Programming
Dienstag, 14. Januar 14
Clean Code -‐ Prak=ken
LernenLiteratur, YoutubePair Programming
49
TrainierenCoding DojosPair Programming
ReflekGerenCoding DojosPair Programming
Dienstag, 14. Januar 14
Clean Code -‐ Wie anfangen? 50
Dienstag, 14. Januar 14
Regeln zu Entwurf und Coding lernen
Clean Code einführen 51
Dienstag, 14. Januar 14
Version Control System: z.B. GIT
Clean Code einführen 52
Dienstag, 14. Januar 14
Issue Tracking -‐ z.B. Jira
Clean Code einführen 53
Dienstag, 14. Januar 14
ConGnuous IntegraGon -‐ z.B. Jenkins
Clean Code einführen 54
Dienstag, 14. Januar 14
Zusammenarbeit im Team: Regeln definieren
Clean Code einführen 55
Dienstag, 14. Januar 14
Messwerte erfassen -‐ KPI‘s
Clean Code einführen 56
Software z.B.SonarEmmaFindbugsCheckstyle
Dienstag, 14. Januar 14
Messwerte erfassen -‐ KPI‘s
Clean Code einführen 56
Tests sind grün
Software z.B.SonarEmmaFindbugsCheckstyle
Dienstag, 14. Januar 14
Messwerte erfassen -‐ KPI‘s
Clean Code einführen 56
offene Tickets
Tests sind grün
Software z.B.SonarEmmaFindbugsCheckstyle
Dienstag, 14. Januar 14
Messwerte erfassen -‐ KPI‘s
Clean Code einführen 56
Testabdeckung
offene Tickets
Tests sind grün
Software z.B.SonarEmmaFindbugsCheckstyle
Dienstag, 14. Januar 14
Messwerte erfassen -‐ KPI‘s
Clean Code einführen 56
Code-‐Format
Testabdeckung
offene Tickets
Tests sind grün
Software z.B.SonarEmmaFindbugsCheckstyle
Dienstag, 14. Januar 14
Messwerte erfassen -‐ KPI‘s
Clean Code einführen 56
VerdächGger Code
Code-‐Format
Testabdeckung
offene Tickets
Tests sind grün
Software z.B.SonarEmmaFindbugsCheckstyle
Dienstag, 14. Januar 14
Messwerte erfassen -‐ KPI‘s
Clean Code einführen 56
CyclomaGc Complexity
VerdächGger Code
Code-‐Format
Testabdeckung
offene Tickets
Tests sind grün
Software z.B.SonarEmmaFindbugsCheckstyle
Dienstag, 14. Januar 14
Technical Debt
Messwerte erfassen -‐ KPI‘s
Clean Code einführen 56
CyclomaGc Complexity
VerdächGger Code
Code-‐Format
Testabdeckung
offene Tickets
Tests sind grün
Software z.B.SonarEmmaFindbugsCheckstyle
Dienstag, 14. Januar 14
Bewertung Trennen
Clean Code einführen 57
Dienstag, 14. Januar 14
Team Monitor
Clean Code einführen 58
Softwarewalldee auf Github
Play & Scala :-)
Dienstag, 14. Januar 14
Clean Code 59
Dienstag, 14. Januar 14
Literatur 60
Dienstag, 14. Januar 14
Literatur 61
Dienstag, 14. Januar 14
Literatur 62
Dienstag, 14. Januar 14
www.clean-‐code-‐developer.de
Literatur 63
Dienstag, 14. Januar 14
Literatur 64
Dienstag, 14. Januar 14
Literatur 65
Dienstag, 14. Januar 14
Literatur 66
Dienstag, 14. Januar 14
Literatur 67
Dienstag, 14. Januar 14
Lorenz HahnKoordinator So?ware Entwicklung
Blücherstr. 2210961 Berlin
fon +49 (0)30-‐609 85 71 91mobil +49 (0)179-‐527 76 83
Xing: hnp://www.xing.com/profiles/Lorenz_Hahn2Linkedin: hnp://de.linkedin.com/in/lorenzhahn
Dienstag, 14. Januar 14
KonGnuierliche Weiterentwicklung der Architektur
Inkrementeller Entwurf 69
Dienstag, 14. Januar 14
Inkrementeller Entwurf 70
Klassisch: Schicht für Schicht mit SchninstellendefiniGon
Dienstag, 14. Januar 14
Inkrementeller Entwurf 71
Inkrementell
Dienstag, 14. Januar 14
Hierbei muss exisGerender Code angepasst werden
Inkrementeller Entwurf 72
=> Refactoring!Dienstag, 14. Januar 14