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 Hahn

1. Clean
Code
-­‐
wozu
eigentlich?
Dienstag, 14. Januar 14

2. Wer
sind
wir?
Dienstag, 14. Januar 14
2

3. Wer
bin
ich?
3
Koordinator
So>wareentwicklung
Scrum-­‐Master
Product-­‐Owner
Teamleiter
Me
=
Lorenz
Dienstag, 14. Januar 14
Dozent
Echtzeit-­‐
&
Prozess-­‐EDV
So>ware-­‐Entwickler

4. Clean
Code
-­‐
wozu
eigentlich?
4
ich
brauche
hier
ein
großes
Loch
Dienstag, 14. Januar 14

5. Clean
Code
-­‐
wozu
eigentlich?
Dienstag, 14. Januar 14
5

6. Anforderungen
an
ein
Produkt
Dienstag, 14. Januar 14
6

7. Anforderungen
an
ein
Produkt
FunkGon
Dienstag, 14. Januar 14
7

8. Anforderungen
an
ein
Produkt
FunkGon
Dienstag, 14. Januar 14
8
Non
FuncGonal
Requirements

9. Anforderungen
an
ein
Produkt
FunkGon
Dienstag, 14. Januar 14
9
Non
FuncGonal
Requirements

10. Anforderungen
an
ein
Produkt
FunkGon
Dienstag, 14. Januar 14
InvesGGonssicherheit
10
Non
Funcitonal
Requrements

11. Anforderungen
an
ein
Produkt
FunkGon
SE
100%
Dienstag, 14. Januar 14
InvesGGonssicherheit
10
Non
Funcitonal
Requrements

12. Anforderungen
an
ein
Produkt
FunkGon
SE
100%
Dienstag, 14. Januar 14
InvesGGonssicherheit
10
Non
Funcitonal
Requrements
SE
25%

13. Anforderungen
an
ein
Produkt
10
FunkGon
InvesGGonssicherheit
Non
Funcitonal
Requrements
SE
100%
Clean
Code
SE
25%
Dienstag, 14. Januar 14

14. Inves==onssicherheit
Dienstag, 14. Januar 14
11

15. Inves==onssicherheit
11
Erhalt
des
Status
Quo
Dienstag, 14. Januar 14

16. Inves==onssicherheit
11
Erhalt
des
Status
Quo
prävenGve
Wartung
Dienstag, 14. Januar 14

17. Inves==onssicherheit
InvesGGonssicherheit
ist
ein
ökonomischer
ImperaGv
Dienstag, 14. Januar 14
12

18. Inves=onssicherheit
bei
So?ware
Dienstag, 14. Januar 14
13

19. Inves=onssicherheit
bei
So?ware
Wartung?
Status
Quo?
Dienstag, 14. Januar 14
13

20. Inves=onssicherheit
bei
So?ware
Wartung?
Status
Quo?
Weiterentwicklung!
Dienstag, 14. Januar 14
13

21. Inves=onssicherheit
bei
So?ware
Wartung?
Status
Quo?
Weiterentwicklung!
prävenGv?
Dienstag, 14. Januar 14
13

22. Inves=onssicherheit
bei
So?ware
Wartung?
Status
Quo?
Weiterentwicklung!
prävenGv?
reakGv!
Dienstag, 14. Januar 14
13

23. Inves=onssicherheit
bei
So?ware
13
Wartung?
Status
Quo?
Weiterentwicklung!
prävenGv?
reakGv!
Inhalt
:
unbekannt!
Dienstag, 14. Januar 14

24. Inves=onssicherheit
bei
So?ware
13
Wartung?
Status
Quo?
Weiterentwicklung!
prävenGv?
reakGv!
Inhalt
:
unbekannt!
Zeitpunkt:
unbekannt!
Dienstag, 14. Januar 14

25. Inves=onssicherheit
bei
So?ware
13
Wartung?
Status
Quo?
Weiterentwicklung!
prävenGv?
reakGv!
Inhalt
:
unbekannt!
Zeitpunkt:
unbekannt!
Schnell
soll‘s
gehen,
kosten
darf‘s
nix.
Dienstag, 14. Januar 14

26. Produk=vität
Dienstag, 14. Januar 14
14

27. Produk=vität
Dienstag, 14. Januar 14
15

28. Produk=vität
Dienstag, 14. Januar 14
16

29. Produk=vität
Dienstag, 14. Januar 14
17

30. Produk=vität
Dienstag, 14. Januar 14
18

31. Evolvierbarkeit
19
jedes
Feature
ist
mit
dem
selben
Aufwand
implemenGerbar,
als
wäre
es
das
erste
Feature
gewesen.
Dienstag, 14. Januar 14

32. Evolvierbarkeit,
Wandelbarkeit
20
jedes
Feature
ist
implemenGerbar,
weil
möglichst
keine
Entscheidung
irreversibel
umgesetzt
wird.
Dienstag, 14. Januar 14

33. Korrektheit
21
die
So>ware
tut
das,
was
man
von
ihr
erwartet.
Dienstag, 14. Januar 14

34. Kon=nuierliche
Verbesserung
22
Mehrfach
tägliches
Refactoring
sorgt
für
steGge
Verbesserung
der
So>ware.
Dienstag, 14. Januar 14

35. Produk=onseffizienz
23
schneller
korrekt
einfacher
angepasst
einfacher
angepasst
leichter
verständlich
leichter
verständlich
Dienstag, 14. Januar 14

36. Kosten?
Dienstag, 14. Januar 14
24

37. Kosten?
Tests
+
Refactoring
Dienstag, 14. Januar 14
24

38. Kosten?
Tests
+
Refactoring
Infrastruktur
Dienstag, 14. Januar 14
24

39. Kosten?
Tests
+
Refactoring
Infrastruktur
Weiterbildung
Dienstag, 14. Januar 14
24

40. Kosten?
24
Tests
+
Refactoring
Infrastruktur
Weiterbildung
Bugs
Dienstag, 14. Januar 14

41. Kosten?
24
Tests
+
Refactoring
Infrastruktur
Weiterbildung
Bugs
Einarbeitung
Dienstag, 14. Januar 14

42. Kosten?
24
Tests
+
Refactoring
Infrastruktur
Weiterbildung
Bugs
Einarbeitung
Aufwand
Dienstag, 14. Januar 14

43. Kosten?
24
Tests
+
Refactoring
Infrastruktur
Weiterbildung
Bugs
Einarbeitung
Aufwand
Schätzungen
Dienstag, 14. Januar 14

44. Was
ist
Clean
Code?
25
Evolvierbarkeit,
Wandelbarkeit,
Korrektheit,
ProdukGonseffizienz
und
konGnuierliche
Verbesserung
sichern.
Dienstag, 14. Januar 14

45. Was
ist
Clean
Code?
26
Handwerk
Dienstag, 14. Januar 14

46. Was
ist
Clean
Code?
27
Mindset
Dienstag, 14. Januar 14

47. Was
ist
Clean
Code?
28
AutomaGsierung
Dienstag, 14. Januar 14

48. Clean
Code
29
Prinzipien
Dienstag, 14. Januar 14

49. Clean
Code
Prinzipien
-­‐
KISS
30
Keep
It
Straight
and
Simple
Dienstag, 14. Januar 14

50. Clean
Code
Prinzipien
-­‐
DRY
31
Don‘t
Repeat
Yourself
Dienstag, 14. Januar 14

51. Clean
Code
Prinzipien
-­‐
YAGNI
32
You
Aren‘t
Going
to
Need
It
Dienstag, 14. Januar 14

52. Clean
Code
Prinzipien
-­‐
PLA
33
Principle
of
Least
Astonishment
Dienstag, 14. Januar 14

53. Clean
Code
Prinzipien
-­‐
SOLID
34
SRP,
OCP,
LSP,
ISP,
DIP
Dienstag, 14. Januar 14

54. Clean
Code
Prinzipien
-­‐
SOLID
35
“There should never be
more than one reason for
a class to change.”
Single
Responsible
Principle
(SRP)
Dienstag, 14. Januar 14

55. Clean
Code
Prinzipien
-­‐
SOLID
36
Open
Closed
Principle
(OCP)
Dienstag, 14. Januar 14

56. Clean
Code
Prinzipien
-­‐
SOLID
36
Offen
für
Erweiterung
Open
Closed
Principle
(OCP)
Dienstag, 14. Januar 14

57. Clean
Code
Prinzipien
-­‐
SOLID
Geschlossen
für
Veränderung
36
Offen
für
Erweiterung
Open
Closed
Principle
(OCP)
Dienstag, 14. Januar 14

58. Clean
Code
Prinzipien
-­‐
SOLID
37
Class Rectangle
Class Square
Liskov
SubsGtuGon
Principle
(LSP)
Dienstag, 14. Januar 14

59. Clean
Code
Prinzipien
-­‐
SOLID
37
Class Rectangle
Class Square
Liskov
SubsGtuGon
Principle
(LSP)
Dienstag, 14. Januar 14

60. Clean
Code
Prinzipien
-­‐
SOLID
37
Class Rectangle
Class Square
Liskov
SubsGtuGon
Principle
(LSP)
Dienstag, 14. Januar 14

61. Clean
Code
Prinzipien
-­‐
SOLID
38
Interface
SegregaGon
Principle
(ISP)
Dienstag, 14. Januar 14

62. Clean
Code
Prinzipien
-­‐
SOLID
39
Dependency
Inversion
Principle
(DIP)
Dienstag, 14. Januar 14

63. Clean
Code
Prinzipien
-­‐
SOLID
39
Dependency
Inversion
Principle
(DIP)
Dienstag, 14. Januar 14

64. Clean
Code
Prinzipien
-­‐
SOLID
39
Dependency
Inversion
Principle
(DIP)
Dienstag, 14. Januar 14

65. Clean
Code
Prinzipien
-­‐
SOLID
39
Dependency
Inversion
Principle
(DIP)
Dienstag, 14. Januar 14

66. Clean
Code
Prinzipien
-­‐
SOLID
39
Dependency
Inversion
Principle
(DIP)
Dienstag, 14. Januar 14

67. Clean
Code
Prinzipien
-­‐
SOLID
39
Dependency
Inversion
Principle
(DIP)
Dienstag, 14. Januar 14

68. Clean
Code
40
PrakGken
Dienstag, 14. Januar 14

69. Clean
Code
-­‐
Prak=ken
Test
First
Unit-­‐Tests
ApplicaGon-­‐Tests
Dienstag, 14. Januar 14
41

70. Clean
Code
-­‐
Prak=ken
42
Test
First
Unit-­‐Tests
ApplicaGon-­‐Tests
Implement
Code-­‐Style
Dienstag, 14. Januar 14

71. Clean
Code
-­‐
Prak=ken
43
Test
First
Unit-­‐Tests
ApplicaGon-­‐Tests
Refactor
SOLID?
Style?
Dienstag, 14. Januar 14
Implement
Code-­‐Style

72. Clean
Code
-­‐
Prak=ken
44
Test
First
Unit-­‐Tests
ApplicaGon-­‐Tests
Refactor
SOLID?
Style?
Dienstag, 14. Januar 14
Implement
Code-­‐Style

73. Clean
Code
-­‐
Prak=ken
-­‐
Style
Dienstag, 14. Januar 14
45

74. Clean
Code
-­‐
Prak=ken
-­‐
Style
z.B.
Kurze
Klassen
&
Methoden
Dienstag, 14. Januar 14
45

75. Clean
Code
-­‐
Prak=ken
-­‐
Style
z.B.
Kurze
Klassen
&
Methoden
z.B.
eindeuGge
und
sprechende
Namen
Dienstag, 14. Januar 14
45

76. Clean
Code
-­‐
Prak=ken
-­‐
Style
z.B.
Kurze
Klassen
&
Methoden
z.B.
eindeuGge
und
sprechende
Namen
z.B.
einheitliche
FormaGerung
Dienstag, 14. Januar 14
45

77. Clean
Code
-­‐
Prak=ken
-­‐
Style
45
z.B.
Kurze
Klassen
&
Methoden
z.B.
eindeuGge
und
sprechende
Namen
z.B.
einheitliche
FormaGerung
z.B.
vermeiden
von
Seiteneffekten
in
FunkGonen
Dienstag, 14. Januar 14

78. Clean
Code
-­‐
Prak=ken
-­‐
Style
45
z.B.
Kurze
Klassen
&
Methoden
z.B.
eindeuGge
und
sprechende
Namen
z.B.
einheitliche
FormaGerung
z.B.
vermeiden
von
Seiteneffekten
in
FunkGonen
z.B.
Anzahl
der
Argumente
in
FunkGonen
Dienstag, 14. Januar 14

79. Clean
Code
-­‐
Prak=ken
-­‐
Style
45
z.B.
Kurze
Klassen
&
Methoden
z.B.
eindeuGge
und
sprechende
Namen
z.B.
einheitliche
FormaGerung
z.B.
vermeiden
von
Seiteneffekten
in
FunkGonen
z.B.
Anzahl
der
Argumente
in
FunkGonen
.....
und
viele,
viele
mehr.
Dienstag, 14. Januar 14

80. Clean
Code
-­‐
Prak=ken
-­‐
Style
45
z.B.
Kurze
Klassen
&
Methoden
z.B.
eindeuGge
und
sprechende
Namen
z.B.
einheitliche
FormaGerung
z.B.
vermeiden
von
Seiteneffekten
in
FunkGonen
z.B.
Anzahl
der
Argumente
in
FunkGonen
.....
und
viele,
viele
mehr.
Sorry.
Dienstag, 14. Januar 14

81. Clean
Code
-­‐
Prak=ken
-­‐
Style
46
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>)
Dienstag, 14. Januar 14

82. Clean
Code
-­‐
Prak=ken
-­‐
Style
47
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)
Dienstag, 14. Januar 14

83. Clean
Code
-­‐
Prak=ken
Version
Control
System
Dienstag, 14. Januar 14
48

84. Clean
Code
-­‐
Prak=ken
Version
Control
System
Issue
Tracking
Features
und
Bugs
Dienstag, 14. Januar 14
48

85. Clean
Code
-­‐
Prak=ken
Version
Control
System
Issue
Tracking
Features
und
Bugs
ConGnuous
IntegraGon
Voll
automaGsierter
Build,
Deploy
und
Test-­‐Zyklus
Erfassung
von
Kennzahlen
(KPI‘s)
Visualisierung
von
Ergebnissen
Dienstag, 14. Januar 14
48

86. Clean
Code
-­‐
Prak=ken
Lernen
Literatur,
Youtube
Pair
Programming
Dienstag, 14. Januar 14
49

87. Clean
Code
-­‐
Prak=ken
Lernen
Literatur,
Youtube
Pair
Programming
Trainieren
Coding
Dojos
Pair
Programming
Dienstag, 14. Januar 14
49

88. Clean
Code
-­‐
Prak=ken
Lernen
Literatur,
Youtube
Pair
Programming
Trainieren
Coding
Dojos
Pair
Programming
ReflekGeren
Coding
Dojos
Pair
Programming
Dienstag, 14. Januar 14
49

89. Clean
Code
-­‐
Wie
anfangen?
Dienstag, 14. Januar 14
50

90. Clean
Code
einführen
51
Regeln
zu
Entwurf
und
Coding
lernen
Dienstag, 14. Januar 14

91. Clean
Code
einführen
52
Version
Control
System:
z.B.
GIT
Dienstag, 14. Januar 14

92. Clean
Code
einführen
53
Issue
Tracking
-­‐
z.B.
Jira
Dienstag, 14. Januar 14

93. Clean
Code
einführen
54
ConGnuous
IntegraGon
-­‐
z.B.
Jenkins
Dienstag, 14. Januar 14

94. Clean
Code
einführen
55
Zusammenarbeit
im
Team:
Regeln
definieren
Dienstag, 14. Januar 14

95. Clean
Code
einführen
Messwerte
erfassen
-­‐
KPI‘s
Soft ware z.B.
Sonar
Emma
Findbugs
Checkstyle
Dienstag, 14. Januar 14
56

96. Clean
Code
einführen
Messwerte
erfassen
-­‐
KPI‘s
Soft ware z.B.
Sonar
Emma
Findbugs
Checkstyle
Dienstag, 14. Januar 14
56
Tests
sind
grün

97. Clean
Code
einführen
Messwerte
erfassen
-­‐
KPI‘s
56
Tests
sind
grün
offene
Tickets
Soft ware z.B.
Sonar
Emma
Findbugs
Checkstyle
Dienstag, 14. Januar 14

98. Clean
Code
einführen
Messwerte
erfassen
-­‐
KPI‘s
56
Tests
sind
grün
offene
Tickets
Testabdeckung
Soft ware z.B.
Sonar
Emma
Findbugs
Checkstyle
Dienstag, 14. Januar 14

99. Clean
Code
einführen
Messwerte
erfassen
-­‐
KPI‘s
56
Tests
sind
grün
offene
Tickets
Testabdeckung
Soft ware z.B.
Sonar
Emma
Findbugs
Checkstyle
Dienstag, 14. Januar 14
Code-­‐Format

100. Clean
Code
einführen
Messwerte
erfassen
-­‐
KPI‘s
56
Tests
sind
grün
offene
Tickets
Testabdeckung
Soft ware z.B.
Sonar
Emma
Findbugs
Checkstyle
Dienstag, 14. Januar 14
Code-­‐Format
VerdächGger
Code

101. Clean
Code
einführen
Messwerte
erfassen
-­‐
KPI‘s
56
Tests
sind
grün
offene
Tickets
Testabdeckung
Soft ware z.B.
Sonar
Emma
Findbugs
Checkstyle
Code-­‐Format
VerdächGger
Code
CyclomaGc
Complexity
Dienstag, 14. Januar 14

102. Clean
Code
einführen
Messwerte
erfassen
-­‐
KPI‘s
56
Tests
sind
grün
offene
Tickets
Testabdeckung
Soft ware z.B.
Sonar
Emma
Findbugs
Checkstyle
Code-­‐Format
VerdächGger
Code
CyclomaGc
Complexity
Technical
Debt
Dienstag, 14. Januar 14

103. Clean
Code
einführen
57
Bewertung
Trennen
Dienstag, 14. Januar 14

104. Clean
Code
einführen
58
Soft ware
walldee auf Github
Play & Scala :-)
Team
Monitor
Dienstag, 14. Januar 14

105. Clean
Code
Dienstag, 14. Januar 14
59

106. Literatur
Dienstag, 14. Januar 14
60

107. Literatur
Dienstag, 14. Januar 14
61

108. Literatur
Dienstag, 14. Januar 14
62

109. Literatur
63
www.clean-­‐code-­‐developer.de
Dienstag, 14. Januar 14

110. Literatur
Dienstag, 14. Januar 14
64

111. Literatur
Dienstag, 14. Januar 14
65

112. Literatur
Dienstag, 14. Januar 14
66

113. Literatur
Dienstag, 14. Januar 14
67

114. Lorenz
Hahn
Koordinator
So?ware
Entwicklung
Blücherstr.
22
10961
Berlin
fon
+49
(0)30-­‐609
85
71
91
mobil
+49
(0)179-­‐527
76
83
lorenz.hahn@leanovate.de
Xing:
hnp://www.xing.com/profiles/Lorenz_Hahn2
Linkedin:
hnp://de.linkedin.com/in/lorenzhahn
Dienstag, 14. Januar 14

115. Inkrementeller
Entwurf
69
KonGnuierliche
Weiterentwicklung
der
Architektur
Dienstag, 14. Januar 14

116. Inkrementeller
Entwurf
70
Klassisch:
Schicht
für
Schicht
mit
SchninstellendefiniGon
Dienstag, 14. Januar 14

117. Inkrementeller
Entwurf
71
Inkrementell
Dienstag, 14. Januar 14

118. Inkrementeller
Entwurf
72
Hierbei
muss
exisGerender
Code
angepasst
werden
=>
Refactoring!
Dienstag, 14. Januar 14