Modernes Software Engineering

1 - Cover [Seite 1]
2 - Stimmen zum Buch [Seite 3]
3 - Impressum [Seite 6]
4 - Inhaltsverzeichnis [Seite 7]
5 - Vorwort [Seite 13]
6 - Einleitung [Seite 17]
6.1 - Eine Definition von Software Engineering? [Seite 19]
6.2 - Der Inhalt des Buchs [Seite 20]
7 - Danksagungen [Seite 21]
8 - Über den Autor [Seite 23]
9 - Teil I: Was ist Software Engineering? [Seite 25]
9.1 - Kapitel 1: Einführung [Seite 27]
9.1.1 - 1.1 Engineering - Die praktische Anwendung von Wissenschaft [Seite 27]
9.1.2 - 1.2 Was ist Software Engineering? [Seite 28]
9.1.3 - 1.3 Die Rückeroberung des »Software Engineering« [Seite 30]
9.1.4 - 1.4 Wie man Fortschritte macht [Seite 30]
9.1.5 - 1.5 Die Geburt des Software Engineering [Seite 31]
9.1.6 - 1.6 Paradigmenwechsel [Seite 33]
9.1.7 - 1.7 Zusammenfassung [Seite 34]
9.2 - Kapitel 2: Was ist Engineering? [Seite 35]
9.2.1 - 2.1 Die Produktion ist nicht unser Problem [Seite 35]
9.2.2 - 2.2 Konstruktionsingenieurwesen, nicht Produktionstechnik [Seite 36]
9.2.3 - 2.3 Eine Arbeitsdefinition von Engineering [Seite 42]
9.2.4 - 2.4 Engineering != Code [Seite 43]
9.2.5 - 2.5 Warum ist Engineering so wichtig? [Seite 45]
9.2.6 - 2.6 Die Grenzen von »Handwerk« [Seite 46]
9.2.7 - 2.7 Präzision und Skalierbarkeit [Seite 47]
9.2.8 - 2.8 Komplexität handhaben [Seite 48]
9.2.9 - 2.9 Reproduzierbarkeit und Messgenauigkeit [Seite 49]
9.2.10 - 2.10 Engineering, Kreativität und Handwerk [Seite 51]
9.2.11 - 2.11 Warum das, was wir tun, kein Software Engineering ist [Seite 53]
9.2.12 - 2.12 Kompromisse [Seite 54]
9.2.13 - 2.13 Die Illusion des Fortschritts [Seite 55]
9.2.14 - 2.14 Der Weg vom Handwerk zum Engineering [Seite 56]
9.2.15 - 2.15 Handwerk ist nicht genug [Seite 57]
9.2.16 - 2.16 Zeit für ein Umdenken? [Seite 58]
9.2.17 - 2.17 Zusammenfassung [Seite 59]
9.3 - Kapitel 3: Grundlagen eines Engineering- Ansatzes [Seite 61]
9.3.1 - 3.1 Eine Branche im Wandel? [Seite 61]
9.3.2 - 3.2 Die Bedeutung von Messungen [Seite 62]
9.3.3 - 3.3 Anwendung von Stabilität und Durchsatz [Seite 65]
9.3.4 - 3.4 Die Grundlagen einer Ingenieursdisziplin für die Software-Entwicklung [Seite 67]
9.3.5 - 3.5 Experten im Lernen [Seite 67]
9.3.6 - 3.6 Experten im Umgang mit Komplexität [Seite 68]
9.3.7 - 3.7 Zusammenfassung [Seite 70]
10 - Teil II: Für das Lernen optimieren [Seite 71]
10.1 - Kapitel 4: Iterativ arbeiten [Seite 73]
10.1.1 - 4.1 Praktische Vorteile iterativen Arbeitens [Seite 75]
10.1.2 - 4.2 Iteration als defensive Design-Strategie [Seite 77]
10.1.3 - 4.3 Der Reiz des Plans [Seite 79]
10.1.4 - 4.4 Praktische Aspekte des iterativen Arbeitens [Seite 86]
10.1.5 - 4.5 Zusammenfassung [Seite 88]
10.2 - Kapitel 5: Feedback [Seite 89]
10.2.1 - 5.1 Ein praktisches Beispiel für die Wichtigkeit von Feedback [Seite 89]
10.2.2 - 5.2 Feedback bei der Entwicklung [Seite 93]
10.2.3 - 5.3 Feedback bei der Integration [Seite 94]
10.2.4 - 5.4 Feedback beim Design [Seite 96]
10.2.5 - 5.5 Feedback zur Architektur [Seite 99]
10.2.6 - 5.6 Frühzeitiges Feedback bevorzugen [Seite 101]
10.2.7 - 5.7 Feedback beim Produktdesign [Seite 102]
10.2.8 - 5.8 Feedback in Unternehmen und Kultur [Seite 103]
10.2.9 - 5.9 Zusammenfassung [Seite 106]
10.3 - Kapitel 6: Inkrementalismus [Seite 107]
10.3.1 - 6.1 Die Bedeutung von Modularität [Seite 108]
10.3.2 - 6.2 Inkrementalismus im Unternehmen [Seite 110]
10.3.3 - 6.3 Werkzeuge für den Inkrementalismus [Seite 112]
10.3.4 - 6.4 Die Auswirkungen von Änderungen begrenzen [Seite 113]
10.3.5 - 6.5 Inkrementelles Design [Seite 115]
10.3.6 - 6.6 Zusammenfassung [Seite 118]
10.4 - Kapitel 7: Empirismus [Seite 119]
10.4.1 - 7.1 In der Realität verankert [Seite 120]
10.4.2 - 7.2 Trennung von Epirismus und Experiment [Seite 120]
10.4.3 - 7.3 »Ich kenne diesen Bug!« [Seite 121]
10.4.4 - 7.4 Selbsttäuschung vermeiden [Seite 123]
10.4.5 - 7.5 Eine Realität erfinden, die zu unserer Argumentation passt [Seite 124]
10.4.6 - 7.6 Von der Realität geleitet [Seite 128]
10.4.7 - 7.7 Zusammenfassung [Seite 129]
10.5 - Kapitel 8: Experimentell vorgehen [Seite 131]
10.5.1 - 8.1 Was bedeutet »experimentell vorgehen«? [Seite 132]
10.5.2 - 8.2 Feedback [Seite 133]
10.5.3 - 8.3 Hypothese [Seite 135]
10.5.4 - 8.4 Messung [Seite 136]
10.5.5 - 8.5 Kontrolle der Variablen [Seite 137]
10.5.6 - 8.6 Automatisierte Tests als Experimente [Seite 138]
10.5.7 - 8.7 Einordnung der Versuchsergebnisse der Tests in den Kontext [Seite 140]
10.5.8 - 8.8 Der Umfang eines Experiments [Seite 142]
10.5.9 - 8.9 Zusammenfassung [Seite 143]
11 - Teil III: Optimieren für den Umgang mit Komplexität [Seite 145]
11.1 - Kapitel 9: Modularität [Seite 147]
11.1.1 - 9.1 Merkmale von Modularität [Seite 148]
11.1.2 - 9.2 Die Bedeutung von gutem Design wird unterschätzt [Seite 149]
11.1.3 - 9.3 Die Bedeutung von Testbarkeit [Seite 151]
11.1.4 - 9.4 Für Testbarkeit zu designen verbessert die Modularität [Seite 152]
11.1.5 - 9.5 Services und Modularität [Seite 159]
11.1.6 - 9.6 Deploybarkeit und Modularität [Seite 161]
11.1.7 - 9.7 Modularität auf verschiedenen Ebenen [Seite 163]
11.1.8 - 9.8 Modularität menschlicher Systeme [Seite 164]
11.1.9 - 9.9 Zusammenfassung [Seite 166]
11.2 - Kapitel 10: Kohäsion [Seite 167]
11.2.1 - 10.1 Modularität und Kohäsion: Grundlagen des Designs [Seite 167]
11.2.2 - 10.2 Der grundlegende Abbau von Kohäsion [Seite 168]
11.2.3 - 10.3 Kontext ist wichtig [Seite 171]
11.2.4 - 10.4 High-Performance-Software [Seite 175]
11.2.5 - 10.5 Verbindung zur Kopplung [Seite 176]
11.2.6 - 10.6 Hohe Kohäsion durch TDD [Seite 177]
11.2.7 - 10.7 Wie erreicht man gute Kohäsion bei Software? [Seite 177]
11.2.8 - 10.8 Kosten von schlechter Kohäsion [Seite 180]
11.2.9 - 10.9 Kohäsion in menschlichen Systemen [Seite 181]
11.2.10 - 10.10 Zusammenfassung [Seite 182]
11.3 - Kapitel 11: Trennung von Zuständigkeiten [Seite 183]
11.3.1 - 11.1 Dependency Injection [Seite 187]
11.3.2 - 11.2 Trennung von wesentlicher und zufälliger Komplexität [Seite 188]
11.3.3 - 11.3 Bedeutung von DDD [Seite 192]
11.3.4 - 11.4 Testbarkeit [Seite 194]
11.3.5 - 11.5 Ports & Adapters [Seite 195]
11.3.6 - 11.6 Wann sollte »Ports & Adapters« eingesetzt werden? [Seite 198]
11.3.7 - 11.7 Was ist eine API? [Seite 199]
11.3.8 - 11.8 Verwendung von TDD zur Förderung der Trennung von Zuständigkeiten [Seite 201]
11.3.9 - 11.9 Zusammenfassung [Seite 202]
11.4 - Kapitel 12: Information Hiding und Abstraktion [Seite 203]
11.4.1 - 12.1 Abstraktion oder Information Hiding [Seite 203]
11.4.2 - 12.2 Was verursacht den »Big Ball of Mud«? [Seite 204]
11.4.3 - 12.3 Unternehmerische und unternehmenskulturelle Probleme [Seite 204]
11.4.4 - 12.4 Technische Probleme und Probleme des Designprozesses [Seite 207]
11.4.5 - 12.5 Furcht vor Over-Engineering [Seite 211]
11.4.6 - 12.6 Verbesserung der Abstraktion durch Testen [Seite 214]
11.4.7 - 12.7 Die Macht der Abstraktion [Seite 215]
11.4.8 - 12.8 Undichte Abstraktionen [Seite 217]
11.4.9 - 12.9 Geeignete Abstraktionen auswählen [Seite 218]
11.4.10 - 12.10 Abstraktionen in der Anwendungsdomäne [Seite 221]
11.4.11 - 12.11 Abstrakte zufällige Komplexität [Seite 222]
11.4.12 - 12.12 Systeme und Code von Drittanbietern isolieren [Seite 225]
11.4.13 - 12.13 Immer das Verbergen von Informationen bevorzugen [Seite 226]
11.4.14 - 12.14 Zusammenfassung [Seite 228]
11.5 - Kapitel 13: Kopplung handhaben [Seite 229]
11.5.1 - 13.1 Kosten von Kopplung [Seite 229]
11.5.2 - 13.2 Hochskalieren [Seite 230]
11.5.3 - 13.3 Microservices [Seite 231]
11.5.4 - 13.4 Entkopplung kann mehr Code bedeuten [Seite 233]
11.5.5 - 13.5 Lose Kopplung ist nicht das Einzige, was wichtig ist [Seite 235]
11.5.6 - 13.6 Lose Kopplung bevorzugen [Seite 236]
11.5.7 - 13.7 Wie unterscheidet sich dies von der Trennung von Zuständigkeiten? [Seite 238]
11.5.8 - 13.8 DRY ist zu simpel [Seite 239]
11.5.9 - 13.9 Asynchronität als Werkzeug für lose Kopplung [Seite 241]
11.5.10 - 13.10 Für lose Kopplung designen [Seite 243]
11.5.11 - 13.11 Lose Kopplung in menschlichen Systemen [Seite 243]
11.5.12 - 13.12 Zusammenfassung [Seite 245]
12 - Teil IV: Werkzeuge zur Unterstützung von Engineering in der Software-Entwicklung [Seite 247]
12.1 - Kapitel 14: Die Werkzeuge einer Ingenieursdisziplin [Seite 249]
12.1.1 - 14.1 Was ist Software-Entwicklung? [Seite 249]
12.1.2 - 14.2 Testbarkeit als Werkzeug [Seite 252]
12.1.3 - 14.3 Messpunkte [Seite 255]
12.1.4 - 14.4 Schwierigkeiten, die Testbarkeit zu erreichen [Seite 256]
12.1.5 - 14.5 Wie man die Testbarkeit verbessert [Seite 260]
12.1.6 - 14.6 Deploybarkeit [Seite 261]
12.1.7 - 14.7 Geschwindigkeit [Seite 263]
12.1.8 - 14.8 Die Variablen kontrollieren [Seite 264]
12.1.9 - 14.9 Continuous Delivery [Seite 266]
12.1.10 - 14.10 Allgemeine Werkzeuge zur Unterstützung von Engineering [Seite 267]
12.1.11 - 14.11 Zusammenfassung [Seite 268]
12.2 - Kapitel 15: Der moderne Software Engineer [Seite 269]
12.2.1 - 15.1 Engineering als menschlicher Prozess [Seite 271]
12.2.2 - 15.2 Digital disruptive Unternehmen [Seite 272]
12.2.3 - 15.3 Ergebnisse vs. Mechanismen [Seite 274]
12.2.4 - 15.4 Langlebigkeit und allgemeine Anwendbarkeit [Seite 277]
12.2.5 - 15.5 Grundlagen einer Ingenieursdisziplin [Seite 280]
12.2.6 - 15.6 Zusammenfassung [Seite 281]
13 - Stichwortverzeichnis [Seite 283]