Tech Talk: Wozu Clean Code?

1,789 views
1,618 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,789
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tech Talk: Wozu Clean Code?

  1. 1. Clean  Code  -­‐  wozu   eigentlich? Dienstag, 14. Januar 14
  2. 2. Wer  sind  wir? Dienstag, 14. Januar 14 2
  3. 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. 4. Clean  Code  -­‐  wozu  eigentlich? 4 ich  brauche  hier  ein  großes  Loch Dienstag, 14. Januar 14
  5. 5. Clean  Code  -­‐  wozu  eigentlich? Dienstag, 14. Januar 14 5
  6. 6. Anforderungen  an  ein  Produkt Dienstag, 14. Januar 14 6
  7. 7. Anforderungen  an  ein  Produkt FunkGon Dienstag, 14. Januar 14 7
  8. 8. Anforderungen  an  ein  Produkt FunkGon Dienstag, 14. Januar 14 8 Non  FuncGonal   Requirements
  9. 9. Anforderungen  an  ein  Produkt FunkGon Dienstag, 14. Januar 14 9 Non  FuncGonal   Requirements
  10. 10. Anforderungen  an  ein  Produkt FunkGon Dienstag, 14. Januar 14 InvesGGonssicherheit 10 Non  Funcitonal   Requrements
  11. 11. Anforderungen  an  ein  Produkt FunkGon SE  100% Dienstag, 14. Januar 14 InvesGGonssicherheit 10 Non  Funcitonal   Requrements
  12. 12. Anforderungen  an  ein  Produkt FunkGon SE  100% Dienstag, 14. Januar 14 InvesGGonssicherheit 10 Non  Funcitonal   Requrements SE  25%
  13. 13. Anforderungen  an  ein  Produkt 10 FunkGon InvesGGonssicherheit Non  Funcitonal   Requrements SE  100% Clean  Code SE  25% Dienstag, 14. Januar 14
  14. 14. Inves==onssicherheit Dienstag, 14. Januar 14 11
  15. 15. Inves==onssicherheit 11 Erhalt  des  Status  Quo Dienstag, 14. Januar 14
  16. 16. Inves==onssicherheit 11 Erhalt  des  Status  Quo prävenGve  Wartung Dienstag, 14. Januar 14
  17. 17. Inves==onssicherheit InvesGGonssicherheit  ist  ein   ökonomischer  ImperaGv Dienstag, 14. Januar 14 12
  18. 18. Inves=onssicherheit  bei  So?ware Dienstag, 14. Januar 14 13
  19. 19. Inves=onssicherheit  bei  So?ware Wartung?  Status  Quo? Dienstag, 14. Januar 14 13
  20. 20. Inves=onssicherheit  bei  So?ware Wartung?  Status  Quo? Weiterentwicklung! Dienstag, 14. Januar 14 13
  21. 21. Inves=onssicherheit  bei  So?ware Wartung?  Status  Quo? Weiterentwicklung! prävenGv? Dienstag, 14. Januar 14 13
  22. 22. Inves=onssicherheit  bei  So?ware Wartung?  Status  Quo? Weiterentwicklung! prävenGv? reakGv! Dienstag, 14. Januar 14 13
  23. 23. Inves=onssicherheit  bei  So?ware 13 Wartung?  Status  Quo? Weiterentwicklung! prävenGv? reakGv! Inhalt  :  unbekannt! Dienstag, 14. Januar 14
  24. 24. Inves=onssicherheit  bei  So?ware 13 Wartung?  Status  Quo? Weiterentwicklung! prävenGv? reakGv! Inhalt  :  unbekannt! Zeitpunkt:  unbekannt! Dienstag, 14. Januar 14
  25. 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. 26. Produk=vität Dienstag, 14. Januar 14 14
  27. 27. Produk=vität Dienstag, 14. Januar 14 15
  28. 28. Produk=vität Dienstag, 14. Januar 14 16
  29. 29. Produk=vität Dienstag, 14. Januar 14 17
  30. 30. Produk=vität Dienstag, 14. Januar 14 18
  31. 31. Evolvierbarkeit 19 jedes  Feature  ist  mit  dem  selben  Aufwand   implemenGerbar,  als  wäre  es  das  erste  Feature  gewesen. Dienstag, 14. Januar 14
  32. 32. Evolvierbarkeit,  Wandelbarkeit 20 jedes  Feature  ist  implemenGerbar,  weil  möglichst   keine  Entscheidung  irreversibel  umgesetzt  wird. Dienstag, 14. Januar 14
  33. 33. Korrektheit 21 die  So>ware  tut  das,  was  man  von  ihr  erwartet. Dienstag, 14. Januar 14
  34. 34. Kon=nuierliche  Verbesserung 22 Mehrfach  tägliches  Refactoring  sorgt  für   steGge  Verbesserung  der  So>ware. Dienstag, 14. Januar 14
  35. 35. Produk=onseffizienz 23 schneller  korrekt einfacher  angepasst einfacher  angepasst leichter  verständlich leichter  verständlich Dienstag, 14. Januar 14
  36. 36. Kosten? Dienstag, 14. Januar 14 24
  37. 37. Kosten? Tests  +  Refactoring Dienstag, 14. Januar 14 24
  38. 38. Kosten? Tests  +  Refactoring Infrastruktur Dienstag, 14. Januar 14 24
  39. 39. Kosten? Tests  +  Refactoring Infrastruktur Weiterbildung Dienstag, 14. Januar 14 24
  40. 40. Kosten? 24 Tests  +  Refactoring Infrastruktur Weiterbildung Bugs Dienstag, 14. Januar 14
  41. 41. Kosten? 24 Tests  +  Refactoring Infrastruktur Weiterbildung Bugs Einarbeitung Dienstag, 14. Januar 14
  42. 42. Kosten? 24 Tests  +  Refactoring Infrastruktur Weiterbildung Bugs Einarbeitung Aufwand Dienstag, 14. Januar 14
  43. 43. Kosten? 24 Tests  +  Refactoring Infrastruktur Weiterbildung Bugs Einarbeitung Aufwand Schätzungen Dienstag, 14. Januar 14
  44. 44. Was  ist  Clean  Code? 25 Evolvierbarkeit,  Wandelbarkeit,   Korrektheit,  ProdukGonseffizienz  und   konGnuierliche  Verbesserung  sichern. Dienstag, 14. Januar 14
  45. 45. Was  ist  Clean  Code? 26 Handwerk Dienstag, 14. Januar 14
  46. 46. Was  ist  Clean  Code? 27 Mindset Dienstag, 14. Januar 14
  47. 47. Was  ist  Clean  Code? 28 AutomaGsierung Dienstag, 14. Januar 14
  48. 48. Clean  Code 29 Prinzipien Dienstag, 14. Januar 14
  49. 49. Clean  Code  Prinzipien  -­‐  KISS 30 Keep  It  Straight  and  Simple Dienstag, 14. Januar 14
  50. 50. Clean  Code  Prinzipien  -­‐  DRY 31 Don‘t  Repeat  Yourself Dienstag, 14. Januar 14
  51. 51. Clean  Code  Prinzipien  -­‐  YAGNI 32 You  Aren‘t  Going  to  Need  It Dienstag, 14. Januar 14
  52. 52. Clean  Code  Prinzipien  -­‐  PLA 33 Principle  of  Least  Astonishment Dienstag, 14. Januar 14
  53. 53. Clean  Code  Prinzipien  -­‐  SOLID 34 SRP,  OCP,  LSP,  ISP,  DIP Dienstag, 14. Januar 14
  54. 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. 55. Clean  Code  Prinzipien  -­‐  SOLID 36 Open  Closed  Principle  (OCP) Dienstag, 14. Januar 14
  56. 56. Clean  Code  Prinzipien  -­‐  SOLID 36 Offen  für   Erweiterung Open  Closed  Principle  (OCP) Dienstag, 14. Januar 14
  57. 57. Clean  Code  Prinzipien  -­‐  SOLID Geschlossen  für   Veränderung 36 Offen  für   Erweiterung Open  Closed  Principle  (OCP) Dienstag, 14. Januar 14
  58. 58. Clean  Code  Prinzipien  -­‐  SOLID 37 Class Rectangle Class Square Liskov  SubsGtuGon  Principle  (LSP) Dienstag, 14. Januar 14
  59. 59. Clean  Code  Prinzipien  -­‐  SOLID 37 Class Rectangle Class Square Liskov  SubsGtuGon  Principle  (LSP) Dienstag, 14. Januar 14
  60. 60. Clean  Code  Prinzipien  -­‐  SOLID 37 Class Rectangle Class Square Liskov  SubsGtuGon  Principle  (LSP) Dienstag, 14. Januar 14
  61. 61. Clean  Code  Prinzipien  -­‐  SOLID 38 Interface  SegregaGon  Principle  (ISP) Dienstag, 14. Januar 14
  62. 62. Clean  Code  Prinzipien  -­‐  SOLID 39 Dependency  Inversion  Principle  (DIP) Dienstag, 14. Januar 14
  63. 63. Clean  Code  Prinzipien  -­‐  SOLID 39 Dependency  Inversion  Principle  (DIP) Dienstag, 14. Januar 14
  64. 64. Clean  Code  Prinzipien  -­‐  SOLID 39 Dependency  Inversion  Principle  (DIP) Dienstag, 14. Januar 14
  65. 65. Clean  Code  Prinzipien  -­‐  SOLID 39 Dependency  Inversion  Principle  (DIP) Dienstag, 14. Januar 14
  66. 66. Clean  Code  Prinzipien  -­‐  SOLID 39 Dependency  Inversion  Principle  (DIP) Dienstag, 14. Januar 14
  67. 67. Clean  Code  Prinzipien  -­‐  SOLID 39 Dependency  Inversion  Principle  (DIP) Dienstag, 14. Januar 14
  68. 68. Clean  Code 40 PrakGken Dienstag, 14. Januar 14
  69. 69. Clean  Code  -­‐  Prak=ken Test  First Unit-­‐Tests ApplicaGon-­‐Tests Dienstag, 14. Januar 14 41
  70. 70. Clean  Code  -­‐  Prak=ken 42 Test  First Unit-­‐Tests ApplicaGon-­‐Tests Implement Code-­‐Style Dienstag, 14. Januar 14
  71. 71. Clean  Code  -­‐  Prak=ken 43 Test  First Unit-­‐Tests ApplicaGon-­‐Tests Refactor SOLID?  Style? Dienstag, 14. Januar 14 Implement Code-­‐Style
  72. 72. Clean  Code  -­‐  Prak=ken 44 Test  First Unit-­‐Tests ApplicaGon-­‐Tests Refactor SOLID?  Style? Dienstag, 14. Januar 14 Implement Code-­‐Style
  73. 73. Clean  Code  -­‐  Prak=ken  -­‐  Style Dienstag, 14. Januar 14 45
  74. 74. Clean  Code  -­‐  Prak=ken  -­‐  Style z.B.  Kurze  Klassen  &  Methoden Dienstag, 14. Januar 14 45
  75. 75. Clean  Code  -­‐  Prak=ken  -­‐  Style z.B.  Kurze  Klassen  &  Methoden z.B.  eindeuGge  und  sprechende  Namen Dienstag, 14. Januar 14 45
  76. 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. 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. 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. 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. 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. 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. 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. 83. Clean  Code  -­‐  Prak=ken Version  Control  System Dienstag, 14. Januar 14 48
  84. 84. Clean  Code  -­‐  Prak=ken Version  Control  System Issue  Tracking Features  und  Bugs Dienstag, 14. Januar 14 48
  85. 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. 86. Clean  Code  -­‐  Prak=ken Lernen Literatur,  Youtube Pair  Programming Dienstag, 14. Januar 14 49
  87. 87. Clean  Code  -­‐  Prak=ken Lernen Literatur,  Youtube Pair  Programming Trainieren Coding  Dojos Pair  Programming Dienstag, 14. Januar 14 49
  88. 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. 89. Clean  Code  -­‐  Wie  anfangen? Dienstag, 14. Januar 14 50
  90. 90. Clean  Code  einführen 51 Regeln  zu  Entwurf  und  Coding  lernen Dienstag, 14. Januar 14
  91. 91. Clean  Code  einführen 52 Version  Control  System:  z.B.  GIT Dienstag, 14. Januar 14
  92. 92. Clean  Code  einführen 53 Issue  Tracking  -­‐  z.B.  Jira Dienstag, 14. Januar 14
  93. 93. Clean  Code  einführen 54 ConGnuous  IntegraGon  -­‐  z.B.  Jenkins Dienstag, 14. Januar 14
  94. 94. Clean  Code  einführen 55 Zusammenarbeit  im  Team:   Regeln  definieren Dienstag, 14. Januar 14
  95. 95. Clean  Code  einführen Messwerte  erfassen  -­‐  KPI‘s Soft ware z.B. Sonar Emma Findbugs Checkstyle Dienstag, 14. Januar 14 56
  96. 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. 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. 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. 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. 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. 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. 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. 103. Clean  Code  einführen 57 Bewertung  Trennen Dienstag, 14. Januar 14
  104. 104. Clean  Code  einführen 58 Soft ware walldee auf Github Play & Scala :-) Team  Monitor Dienstag, 14. Januar 14
  105. 105. Clean  Code Dienstag, 14. Januar 14 59
  106. 106. Literatur Dienstag, 14. Januar 14 60
  107. 107. Literatur Dienstag, 14. Januar 14 61
  108. 108. Literatur Dienstag, 14. Januar 14 62
  109. 109. Literatur 63 www.clean-­‐code-­‐developer.de Dienstag, 14. Januar 14
  110. 110. Literatur Dienstag, 14. Januar 14 64
  111. 111. Literatur Dienstag, 14. Januar 14 65
  112. 112. Literatur Dienstag, 14. Januar 14 66
  113. 113. Literatur Dienstag, 14. Januar 14 67
  114. 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. 115. Inkrementeller  Entwurf 69 KonGnuierliche  Weiterentwicklung  der  Architektur Dienstag, 14. Januar 14
  116. 116. Inkrementeller  Entwurf 70 Klassisch:  Schicht  für  Schicht  mit   SchninstellendefiniGon   Dienstag, 14. Januar 14
  117. 117. Inkrementeller  Entwurf 71 Inkrementell Dienstag, 14. Januar 14
  118. 118. Inkrementeller  Entwurf 72 Hierbei  muss  exisGerender  Code  angepasst  werden =>  Refactoring! Dienstag, 14. Januar 14

×