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



Erhalt des Status Quo

prävenGve Wartung




InvesGGonssicherheit ist ein

ökonomischer ImperaGv


Inves=onssicherheit bei So?ware 13


Wartung? Status Quo?



Weiterentwicklung!




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


Bugs

Infrastruktur

Tests + Refactoring

Weiterbildung

Kosten? 24


Einarbeitung

Bugs

Infrastruktur

Tests + Refactoring

Weiterbildung

Kosten? 24


Einarbeitung

Bugs

Aufwand

Infrastruktur

Tests + Refactoring

Weiterbildung

Kosten? 24


Einarbeitung

Bugs

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




Offen für Erweiterung

Geschlossen für Veränderung



Liskov SubsGtuGon Principle (LSP)


Class Rectangle

Class Square


Interface SegregaGon Principle (ISP)



Dependency Inversion Principle (DIP)



PrakGken

Clean Code 40


Clean Code -‐ Prak=ken

Test FirstUnit-‐TestsApplicaGon-‐Tests

41




42

ImplementCode-‐Style




43

RefactorSOLID? Style?





44

RefactorSOLID? Style?



Clean Code -‐ Prak=ken -‐ Style 45


Clean Code -‐ Prak=ken -‐ Style

z.B. Kurze Klassen & Methoden

45



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

45



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

45



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

45



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



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



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


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

48




48

Issue TrackingFeatures und Bugs




48

Issue TrackingFeatures und Bugs

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



LernenLiteratur, YoutubePair Programming

49




49

TrainierenCoding DojosPair Programming




49

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


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

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

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

[email protected]

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


mailto:[email protected]

mailto:[email protected]

https://www.xing.com/profiles/Vlore_Kryeziu

https://www.xing.com/profiles/Vlore_Kryeziu

http://de.linkedin.com/pub/vlore-kryeziu/31/82b/8b5

http://de.linkedin.com/pub/vlore-kryeziu/31/82b/8b5

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