Farley Modernes Software Engineering

Bessere Software schneller und effektiver entwickeln
1., 2024
ISBN: 978-3-7475-0635-6
Verlag: mitp Verlags GmbH & Co.KG
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 288 Seiten

Reihe: mitp Professional

• Deutsche Ausgabe des Bestsellers von dem Pionier für Continuous Delivery
• Verbessern Sie Ihre Effektivität, Ihre Kreativität und damit auch Ihren Code
• Praktischer Leitfaden für Programmierer, technische Leiter und Manager

»Es gibt viele Bücher, die Ihnen sagen, wie Sie ein bestimmtes Software-Engineering-Verfahren anwenden sollen; dieses Buch ist anders. […] Es ist ein Buch für jeden, der die Softwareentwicklung ernsthaft als echte Ingenieursdisziplin behandeln möchte, egal ob Sie gerade erst anfangen oder schon seit Jahrzehnten Software entwickeln.«
— Dave Hounslow, Software Engineer

In diesem Buch gibt Ihnen der Continuous-Delivery-Pionier David Farley praktische Strategien an die Hand, mit denen Sie Software-Projekte effektiver umsetzen, erfolgreicher managen und die Qualität Ihrer Programme grundlegend verbessern können – und damit auch Ihre tägliche Arbeit.

David Farley richtet sich an Programmierer, technische Leiter und Manager unabhängig von ihrer Erfahrung. Er beleuchtet langlebige Strategien und Prinzipien, die das Herzstück der effektiven Softwareentwicklung bilden. Dabei unterscheidet er zwischen zwei Kerndisziplinen: Erkunden und Lernen sowie Umgang mit Komplexität. Für jede der beiden vermittelt er praxisnahe Konzepte und Prinzipien, die Ihnen helfen, den gesamten Entwicklungsprozess zu verbessern, von Ihrer Denkweise bis hin zur Qualität Ihres Codes. Dafür beschreibt er effektive Strategien, die nachweislich zum Erfolg führen.

Farleys Konzepte und Techniken bilden einen ganzheitlichen, wissenschaftlichen und fundierten Ansatz zur Lösung praktischer Probleme bei der Softwareentwicklung unter realistischen wirtschaftlichen Bedingungen. Dieser allgemeingültige und langlebige Ansatz kann Ihnen helfen, sogar Probleme zu lösen, die Ihnen bisher nie begegnet sind. Er bietet Ihnen einen tiefen Einblick in Ihre tägliche Arbeit und unterstützt sie dabei, bessere Software schneller, effektiver und mit mehr Freude zu entwickeln.

Zielgruppe

Programmierer, Manager und technische Leiter

Autoren/Hrsg.

Farley, David

Inhaltsverzeichnis

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

Über Autor(innen)

David Farley ist Gründer und Consultant von Continuous Delivery Ltd und verfügt über jahrelange Erfahrung als Programmierer, Software Engineer und Systemarchitekt. Seine bahnbrechenden Ansätze haben die Arbeit von Entwicklern und Teams revolutioniert. Als Head of Software Development für London Multi Asset Exchange (LMAX) hat er eines der schnellsten Finanzsysteme der Welt aufgebaut. Er war einer der ersten, der agile Methoden wie Continuous Integration und automatisierte Tests angewendet hat und ist Betreiber des erfolgreichen Youtube-Kanals »Continuous Delivery«.