Details

Clean Code für Dummies


Clean Code für Dummies


Für Dummies 1. Aufl.

von: Jürgen Lampe

18,99 €

Verlag: Wiley-VCH
Format: EPUB
Veröffentl.: 30.04.2020
ISBN/EAN: 9783527823925
Sprache: deutsch
Anzahl Seiten: 298

DRM-geschütztes eBook, Sie benötigen z.B. Adobe Digital Editions und eine Adobe ID zum Lesen.

Beschreibungen

Clean Code ist eine wichtige Methode, um zu besserer Software zu kommen. Zu beachten sind Korrektheit, Verständlichkeit, Lesbarkeit und Ressourcenverbrauch. Programmieren ist aber mehr als ein Handwerk. Klarer Code ist auch Ausdruck klaren Denkens und beginnt damit schon vor der Niederschrift. Regeln sind wichtige Stützen, aber das eigenständige Denken, Entscheiden und Abwägen ersetzen sie nicht. Das Buch vermittelt handwerkliche Fertigkeiten und stellt das Programmieren in den Gesamtprozess der Softwareentwicklung.
<p>Über den Autor 9</p> <p><b>Einleitung 23</b></p> <p>Über dieses Buch 23</p> <p>Konventionen in diesem Buch 24</p> <p>Was Sie nicht lesen müssen 24</p> <p>Törichte Annahmen über die Leser 25</p> <p>Wie dieses Buch aufgebaut ist 26</p> <p>Symbole, die in diesem Buch verwendet werden 27</p> <p>Wie es weitergeht 28</p> <p><b>Teil I: Das Clean-Code-Prinzip 29</b></p> <p><b>Kapitel 1 Software ist Code31</b></p> <p>Erwartungen an Software 31</p> <p>Probleme haben Ursachen 32</p> <p>Allgemeine Ursachen 32</p> <p>Hardwareentwicklung 33</p> <p>Nichts ohne Code 34</p> <p>Das Wichtigste in Kürze 35</p> <p><b>Kapitel 2 Dimensionen von Codequalität</b> <b>37</b></p> <p>Was bedeutet Qualität? 37</p> <p>Eigenschaften des Qualitätsbegriffs 37</p> <p>Qualitätsindikatoren 38</p> <p>Die Dimensionen von Codequalität 39</p> <p>Korrektheit des Codes 39</p> <p>Lesbarkeit und Wartbarkeit 40</p> <p>Leistungseigenschaften 40</p> <p>Weitere Dimensionen 41</p> <p>Das Qualitätsziel festlegen 41</p> <p>Beispiel: Der euklidische Algorithmus 42</p> <p>Das Wichtigste in Kürze 43</p> <p><b>Kapitel 3 Alles unter einen Hut – gute Kompromisse finden 45</b></p> <p>Warum gute Entscheidungen wichtig sind 45</p> <p>Es kommt drauf an 45</p> <p>Widersprüche überall 46</p> <p>Konflikte akzeptieren 47</p> <p>Entscheidungen systematisch treffen 48</p> <p>Konflikte erkennen 48</p> <p>Alternativen sammeln 48</p> <p>Kriterien finden 49</p> <p>Wahlmöglichkeiten bewerten 50</p> <p>Entscheiden 51</p> <p>Mit Augenmaß 51</p> <p>Das Wichtigste in Kürze 52</p> <p><b>Kapitel 4 Die Eigenschaften sauberen Codes</b> <b>55</b></p> <p>Des Clean Codes Kern 55</p> <p>Code als Ziel 56</p> <p>Professionalität 57</p> <p>Es geht immer weiter 58</p> <p>Code als Kommunikationsmittel zwischen Menschen 58</p> <p>Lesbarkeit 59</p> <p>Verständlichkeit 59</p> <p>Eleganz 60</p> <p>Gute Wartbarkeit 61</p> <p>Leichter durch Verständlichkeit 61</p> <p>Nicht ohne Test 61</p> <p>Zu guter Letzt 62</p> <p>Das Wichtigste in Kürze 63</p> <p><b>Kapitel 5 In der Praxis: Stolpersteine 65</b></p> <p>Clean Code ist schwer 65</p> <p>Reden wir über die Kosten 65</p> <p>Kurz- und mittelfristige Vorteile 66</p> <p>Langfristige Vorteile 66</p> <p>Bewertung 68</p> <p>Ändern bleibt schwierig 68</p> <p>Manchmal passt es nicht 69</p> <p>Frameworks 70</p> <p>Projektvorgaben 70</p> <p>Starre Abläufe 71</p> <p>Falsche Autoritäten 71</p> <p>Es liegt an Ihnen 73</p> <p>Das Wichtigste in Kürze 73</p> <p><b>Teil II: An Herausforderungen wachsen 75</b></p> <p><b>Kapitel 6 Mehr als Handwerkskunst</b> <b>77</b></p> <p>Programmieren ist schwer 77</p> <p>Software professionell entwickeln 79</p> <p>Softwareentwicklung braucht Handwerk 80</p> <p>Handwerk allein reicht nicht 82</p> <p>Das Wichtigste in Kürze 83</p> <p><b>Kapitel 7 Entwickeln ist (kreative) Wissenschaft 85</b></p> <p>Formalisiertes Wissen 85</p> <p>Was sind formale Theorien? 86</p> <p>Wann braucht es eine (neue) Theorie? 87</p> <p>Wie Sie zu einer Theorie kommen? 88</p> <p>Mentales Modell als Theorie 88</p> <p>Wenn es so einfach wäre: Viele Hürden 89</p> <p>Und dann auch noch der kleine Rest 90</p> <p>Konsequenzen 91</p> <p>Die Bedeutung des Entwicklers darf nicht unterschätzt werden 91</p> <p>Es werden verschiedene Qualifikationen gebraucht 92</p> <p>Auch die Theorie muss weiterentwickelt werden 93</p> <p>Das Wichtigste in Kürze 94</p> <p><b>Kapitel 8 Modellierungsdilemma und Entscheidungsmüdigkeit 95</b></p> <p>Das Modellierungsdilemma 95</p> <p>Was macht ein Modell aus? 95</p> <p>Ein Modell für alle Anforderungen gesucht 96</p> <p>Und wenn es kein umfassendes Modell gibt? 98</p> <p>Entscheiden ermüdet 100</p> <p>Entwickeln heißt entscheiden 100</p> <p>Entscheidungskraft optimal nutzen 101</p> <p>Das Wichtigste in Kürze 103</p> <p><b>Kapitel 9 Fallen vermeiden 105</b></p> <p>Erst mal loslegen 105</p> <p>Agil heißt nicht »kein Konzept« 105</p> <p>Abgrenzung ist alles 106</p> <p>Wenn es nicht anders geht 107</p> <p>Schön flexibel bleiben 108</p> <p>Flexible Programme 109</p> <p>Flexibilität bläht auf 109</p> <p>Die Sinnfrage 110</p> <p>Modularisierung übertreiben 111</p> <p>Davon verschwindet die Komplexität nicht 111</p> <p>Zerlegung will geübt sein 112</p> <p>Schon wieder: Kosten 113</p> <p>Wachsen im Korsett 113</p> <p>Das Wichtigste in Kürze 114</p> <p><b>Teil III: Sauberen Code schreiben 115</b></p> <p><b>Kapitel 10 Namen sind nicht Schall und Rauch 117</b></p> <p>Benennungen 117</p> <p>Namen versus Bezeichner 118</p> <p>Namen versus Begriffe 118</p> <p>Woher nehmen? 120</p> <p>Lösungsdomäne 120</p> <p>Anwendungsdomäne 120</p> <p>Eigenschaften guter Namen 121</p> <p>Den Sinn vermitteln 121</p> <p>Nicht in die Irre führen 121</p> <p>Sinnvolle Unterschiede 122</p> <p>Verschlüsselungen vermeiden 123</p> <p>Verwendbarkeit 124</p> <p>Klassen und Methoden 125</p> <p>Die Qual der Sprachwahl 125</p> <p>Englisch 126</p> <p>Deutsch 126</p> <p>Keine Empfehlung 126</p> <p>Was zu tun ist 127</p> <p>Das Wichtigste in Kürze 127</p> <p><b>Kapitel 11 Reine Formfrage – Formatierung</b> <b>129</b></p> <p>Das Auge liest mit 129</p> <p>Vertikales Formatieren 131</p> <p>Codelänge 131</p> <p>Vorbild Zeitung 131</p> <p>Vertikale Abstände 132</p> <p>Vertikale Ordnung 134</p> <p>Horizontales Formatieren 135</p> <p>Zeilenlänge 135</p> <p>Horizontale Abstände 136</p> <p>Einrückungen 138</p> <p>Automatische Formatierung 139</p> <p>Vorteile 139</p> <p>Nachteile 140</p> <p>Das Wichtigste in Kürze 140</p> <p><b>Kapitel 12 Code zuerst – sind Kommentare nötig? 141</b></p> <p>Code allein reicht nicht 141</p> <p>Erklärung gesucht 141</p> <p>Das große Missverständnis: Code spricht nur den Computer an 142</p> <p>Kommentare – hilfreich oder störend? 142</p> <p>Kommentare lügen – oft 143</p> <p>Sinnvolle Kommentare 143</p> <p>Rechtshinweise 143</p> <p>Unerledigtes 143</p> <p>Klarstellungen und Warnungen 144</p> <p>Algorithmen 144</p> <p>Spezifikationen 144</p> <p>Pragmatisches 146</p> <p>Schlechte Kommentare 147</p> <p>Nichtssagendes 147</p> <p>Auskommentierter Code 148</p> <p>Unterschiedliche Sprachen 148</p> <p>Fehlender Bezug 148</p> <p>JavaDoc 149</p> <p>Dokumentationen 150</p> <p>Schönheit 151</p> <p>Das Wichtigste in Kürze 152</p> <p><b>Kapitel 13 Kleine Schritte – saubere Methoden</b> <b>153</b></p> <p>Methoden 153</p> <p>Begriffliche Klärung 154</p> <p>Eigenschaften 154</p> <p>Der Inhalt 155</p> <p>Abstraktion 155</p> <p>Trennung von Bearbeitung und Abfrage 155</p> <p>Testen 156</p> <p>Die Größe 156</p> <p>Eine Aufgabe 156</p> <p>Zeilenzahl 157</p> <p>Schachtelungsstruktur 158</p> <p>Parameter 159</p> <p>Anzahl 160</p> <p>Stellung 162</p> <p>Parameter vermeiden 162</p> <p>Testen 163</p> <p>Flag-Parameter 163</p> <p>Resultate 164</p> <p>Rückgabewerte 164</p> <p>Rückgabewert null 165</p> <p>Ergebnisparameter 166</p> <p>Rückkehrcodes 167</p> <p>Seiteneffekte 167</p> <p>Auswahlanweisungen 168</p> <p>Alles fließt 170</p> <p>Das Wichtigste in Kürze 170</p> <p><b>Kapitel 14 Passend schneiden – Schnittstellen 171</b></p> <p>Die Rolle von Schnittstellen 171</p> <p>Mehr als ein Interface 171</p> <p>Isoliert betrachtet 172</p> <p>Im Verbund 172</p> <p>Komponenten 173</p> <p>Interface Segregation 174</p> <p>Schlanke Schnittstellen 174</p> <p>Kohäsion 175</p> <p>Kombination 179</p> <p>Keine Missverständnisse 180</p> <p>Exakte Beschreibung 180</p> <p>Voraussetzungen aufführen 181</p> <p>Vollständige Definition 182</p> <p>Tests und Mocks 182</p> <p>Kein Code ohne Fremdcode 183</p> <p>Eine unsichtbare Grenze 184</p> <p>Abhängigkeiten isolieren 184</p> <p>Wie es gehen könnte 185</p> <p>Das Wichtigste in Kürze 189</p> <p><b>Kapitel 15 Objekte und Datensätze unterscheiden</b> <b>191</b></p> <p>Was ist ein Objekt? 191</p> <p>Und ein Datensatz? 192</p> <p>Die Praxis 193</p> <p>Die Objekt-Datensatz-Antisymmetrie 194</p> <p>Java und Objektorientierung 194</p> <p>Prozeduraler Code 195</p> <p>Objektorientierter Code 197</p> <p>Schlussfolgerungen 199</p> <p>Das Gesetz von Demeter 199</p> <p>Internes intern halten 200</p> <p>Trotzdem kommunikativ sein 200</p> <p>Das gilt auch umgekehrt 202</p> <p>Aufrufketten 203</p> <p>Fazit 205</p> <p>Das Wichtigste in Kürze 205</p> <p><b>Kapitel 16 Wege im Dschungel – Regeln 207</b></p> <p>Wiederholungen vermeiden 207</p> <p>Die Regel 207</p> <p>Motivation 208</p> <p>Umsetzung 209</p> <p>Schwierigkeiten 210</p> <p>Liefern, was verlangt wird 211</p> <p>Die Regel 211</p> <p>Motivation 212</p> <p>Umsetzung 212</p> <p>Schwierigkeiten 213</p> <p>Jedes für sich 213</p> <p>Die Regel 213</p> <p>Motivation 214</p> <p>Umsetzung 214</p> <p>Schwierigkeiten 214</p> <p>Die SOLID-Regeln 215</p> <p>Single Responsibility Principle – SRP 215</p> <p>Open Closed Principle – OCP 216</p> <p>Liskov Substitution Principle – LSP 217</p> <p>Interface Segregation Principle – ISP 217</p> <p>Dependency Inversion Principle – DIP 217</p> <p>Einfach besser 218</p> <p>Halte es einfach 218</p> <p>Geringste Überraschung 219</p> <p>Fazit 219</p> <p>Das Wichtigste in Kürze 219</p> <p><b>Kapitel 17 Fehler passieren – Fehlerbehandlung221</b></p> <p>Ausgangslage 221</p> <p>Fehlerarten 222</p> <p>Datenfehler 222</p> <p>Seltene Datenfehler 223</p> <p>Häufige Datenfehler 223</p> <p>Funktionsfehler 225</p> <p>Hardwarefehler 226</p> <p>Semantische Fehler 227</p> <p>Plausibilitätsprüfung 227</p> <p>Wertebereichs-Überschreitungen 229</p> <p>Keine Panik 231</p> <p>Das Wichtigste in Kürze 231</p> <p><b>Kapitel 18 Ausnahmen regeln – Exceptions 233</b></p> <p>Sinn und Zweck 233</p> <p>Checked und Unchecked Exceptions 234</p> <p>Kosten 235</p> <p>Werfen von Exceptions 235</p> <p>Generische Exceptions verwenden 235</p> <p>Spezielle Exceptions definieren 236</p> <p>Fangen von Exceptions 238</p> <p>Funktionsblöcke bestimmen 238</p> <p>Fachliche und technische Exceptions 239</p> <p>Verpacken von Exceptions 240</p> <p>Loggen von Exceptions 240</p> <p>Angemessenheit 241</p> <p>Das Wichtigste in Kürze 242</p> <p><b>Kapitel 19 Immer weiter – neue Sprachmittel</b> <b>243</b></p> <p>Wie beurteilen? 243</p> <p>Annotationen 245</p> <p>Funktion 246</p> <p>Anwendungsarten 246</p> <p>Risiken minimieren 248</p> <p>Lambda-Ausdrücke 248</p> <p>Klippen 248</p> <p>So vielleicht 250</p> <p>Streams 251</p> <p>Die Idee 252</p> <p>Anwendung 252</p> <p>Aber Vorsicht 253</p> <p>Fazit 254</p> <p>Spezialisierung 254</p> <p>Beschränkung 255</p> <p>Das Wichtigste in Kürze 256</p> <p><b>Teil IV: Wege zum Ziel 257</b></p> <p><b>Kapitel 20 Miteinander lernen – Code Reviews 259 </b></p> <p>Zweck 260</p> <p>Was nicht geht 260</p> <p>Das Potenzial 261</p> <p>Durchführung 262</p> <p>Erfolgsvoraussetzungen 262</p> <p>Vorbereitung 263</p> <p>Review-Rollen 265</p> <p>Review-Werkzeuge und Metriken 266</p> <p>Review-Bewertung 267</p> <p>Codequalität 267</p> <p>Review-Qualität 267</p> <p>Das Wichtigste in Kürze 268</p> <p><b>Kapitel 21 Aus Fehlern lernen 269</b></p> <p>Fehler macht jeder 269</p> <p>Fehler analysieren 270</p> <p>Fehlerursachen ermitteln 271</p> <p>Fehlerarten 272</p> <p>Priorisierung 272</p> <p>Denken Sie an … 273</p> <p>Erkenntnisse nutzen 275</p> <p>Code Reviews nutzen 275</p> <p>Ergebnisse dokumentieren 275</p> <p>Wiederholen: Erkenntnisse erneut erörtern 275</p> <p>Das Wichtigste in Kürze 276</p> <p><b>Kapitel 22 Es gibt immer was zu tun – Refactoring 277</b></p> <p>Die Idee 277</p> <p>Die Praxis 278</p> <p>Vorbereitung 278</p> <p>Schritt für Schritt 280</p> <p>Im Großen und im Kleinen 280</p> <p>Ein Beispiel 281</p> <p>Das Wichtigste in Kürze 282</p> <p><b>Teil V: Der Top-Ten-Teil 283</b></p> <p><b>Kapitel 23 10 Fehler, die Sie vermeiden sollten 285</b></p> <p>Buch in Schrank stellen 285</p> <p>Nicht sofort anfangen 285</p> <p>Aufgeben 286</p> <p>Nicht streiten 286</p> <p>Schematisch anwenden 286</p> <p>Kompromisse verweigern 286</p> <p>Unrealistische Terminzusagen 287</p> <p>Überheblichkeit 287</p> <p>Denken, fertig zu sein 287</p> <p>Alles tierisch ernst nehmen 287</p> <p><b>Kapitel 24 (Mehr als) 10 nützliche Quellen zum Auffrischen und Vertiefen 289</b></p> <p>Clean Code – das Buch und der Blog 289</p> <p>Clean Code Developer 290</p> <p>Software Craftsmanship 290</p> <p>Java Code Conventions 290</p> <p>97 Dinge, die jeder Programmierer wissen sollte 290</p> <p>The Pragmatic Bookshelf 291</p> <p>Prinzipien der Softwaretechnik 291</p> <p>Refactoring 291</p> <p>Code Reviews 291</p> <p>Codeanalyse 292</p> <p>Verzögerungskosten 292</p> <p>Project Oberon 292</p> <p>Stichwortverzeichnis 295</p>
Jürgen Lampe ist IT-Berater in Eschborn in der Nähe von Frankfurt. Er hat Mathematik studiert, Prozessrechenanlagen programmiert und als Hochschullehrer an der TU Dresden gearbeitet. Über die Jahre hat er nie das Coden aufgegeben. Er kennt diverse Programmiersprachen - von Algol60 über PL/I und Pascal bis zu Java - und er kennt die Vor- und Nachteile verschiedener Programmierstile.

Diese Produkte könnten Sie auch interessieren:

Domain Architectures
Domain Architectures
von: Daniel J. Duffy
PDF ebook
31,99 €