Seemann Code That Fits in Your Head

Heuristiken für die Softwareentwicklung. Komplexität reduzieren | Legacy Code beherrschen | Performance optimieren
1. Auflage 2022
ISBN: 978-3-7475-0515-1
Verlag: mitp Verlags GmbH & Co.KG
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 368 Seiten

Reihe: mitp Professional

Techniken und Konzepte für nachhaltige Softwareentwicklung sowie sauberen und wartbaren CodeReduktion von Komplexität, strukturierte Arbeitsabläufe und effiziente FehlerbehandlungMit Auszügen aus einem vollständigen Beispielprojekt inklusive Code zum Download»Mark Seemann ist dafür bekannt, komplexe Konzepte anschaulich und präzise zu erläutern. In diesem Buch kondensiert er seine weitreichende Erfahrung in der Softwareentwicklung zu praktischen, pragmatischen Techniken für nachhaltigen und gut lesbaren Code. Dieses Buch ist ein Must Read für jeden Programmierer.«– Scott Wlaschin, Autor von »Domain Modeling Made Functional«Dieses Buch ist ein praktischer Leitfaden für das Schreiben von nachhaltigem Programmcode und die Reduktion von Komplexität. So können Sie verhindern, dass Softwareprojekte langfristig außer Kontrolle geraten.Mark Seemann unterstützt seit Jahrzehnten Softwareentwickler-Teams bei der erfolgreichen Umsetzung ihrer Projekte. In diesem Buch begleitet er Sie von den ersten Codezeilen bis zum Deployment und zeigt Ihnen, wie Sie im Entwicklungsprozess effizient und nachhaltig bleiben, wenn Sie neue Funktionalitäten implementieren. Dabei legt er auch Wert auf Fehlerbehandlung und disziplinübergreifende Themen. Er gibt Ihnen wertvolle Hinweise, Techniken und Arbeitsabläufe für alle wichtigen Kernprobleme an die Hand: von der Verwendung von Checklisten bis zur Teamarbeit, von Kapselung bis zur verteilten Programmierung, von API-Design bis zu Unit Testing.Seemann veranschaulicht seine Konzepte anhand von Codebeispielen aus einem vollständigen Projektbeispiel in C#. Der Code ist so geschrieben, dass er gut verständlich für jeden ist, der eine objektorientierte Programmiersprache verwendet, einschließlich Java, C++ und Python. Der gesamte Code steht zur weiteren Erkundung zum Download bereit.Wenn Sie jemals negative Erfahrungen bei der Umsetzung von Softwareprojekten oder mit schlecht wartbarem Legacy Code gemacht haben, wird dieses Praxisbuch Ihnen helfen, solchen Schwierigkeiten ab sofort aus dem Weg zu gehen.Aus dem Inhalt:Den passenden Workflow wählen und schlechten Metaphern entkommen, die nicht funktionierenMit Checklisten mehr Freiheiten schaffen und das Ergebnis verbessern, indem Sie die Fähigkeiten nutzen, über die Sie bereits verfügenCode Rot und unnötige Komplexität vermeidenBessere Techniken meistern und neue Routinen bei der Programmierung etablierenNeue Wege für effektivere und schnellere FehlerbehandlungHöhere Produktivität in Bezug auf Performance und Sicherheit

Zielgruppe

Programmierer und Softwareentwickler

Autoren/Hrsg.

Seemann, Mark

Inhaltsverzeichnis

1;Cover;1
2;Titel;7
3;Impressum;8
4;Inhaltsverzeichnis;9
5;Vorwort des Herausgebers der englischen Ausgabe;17
6;Einleitung;21
7;Über den Autor;27
8;Teil I: Beschleunigung;29
8.1;Kapitel 1: Kunst oder Wissenschaft?;31
8.1.1;1.1 Bau eines Hauses;31
8.1.1.1;1.1.1 Das Problem mit Projekten;32
8.1.1.2;1.1.2 Das Problem mit Phasen;33
8.1.1.3;1.1.3 Abhängigkeiten;33
8.1.2;1.2 Kultivieren eines Gartens;34
8.1.2.1;1.2.1 Was lässt einen Garten gedeihen?;35
8.1.3;1.3 Der Weg zur Ingenieurswissenschaft;35
8.1.3.1;1.3.1 Software als Kunsthandwerk;35
8.1.3.2;1.3.2 Heuristik;37
8.1.3.3;1.3.3 Ältere Vorstellungen von Software Engineering;38
8.1.3.4;1.3.4 Fortschritte beim Software Engineering;39
8.1.4;1.4 Fazit;40
8.2;Kapitel 2: Checklisten;43
8.2.1;2.1 Eine Gedächtnisstütze;43
8.2.2;2.2 Checkliste für eine neue Codebasis;45
8.2.2.1;2.2.1 Git verwenden;46
8.2.2.2;2.2.2 Build automatisieren;47
8.2.2.3;2.2.3 Alle Fehlermeldungen aktivieren;51
8.2.3;2.3 Überprüfungen zu einer vorhandenen Codebasis hinzufügen;56
8.2.3.1;2.3.1 Schrittweise Verbesserungen;57
8.2.3.2;2.3.2 Hacken Sie Ihre Organisation;58
8.2.4;2.4 Fazit;59
8.3;Kapitel 3: Komplexität in den Griff bekommen;61
8.3.1;3.1 Ziel;61
8.3.1.1;3.1.1 Nachhaltigkeit;62
8.3.1.2;3.1.2 Nutzwert;63
8.3.2;3.2 Warum Programmieren schwierig ist;65
8.3.2.1;3.2.1 Die Gehirn-Metapher;65
8.3.2.2;3.2.2 Code wird häufiger gelesen als geschrieben;66
8.3.2.3;3.2.3 Verständlichkeit;67
8.3.2.4;3.2.4 Geistige Arbeit;68
8.3.3;3.3 Software Engineering;70
8.3.3.1;3.3.1 Beziehung zur Informatik;71
8.3.3.2;3.3.2 Menschenfreundlicher Code;71
8.3.4;3.4 Fazit;72
8.4;Kapitel 4: Vertical Slice;75
8.4.1;4.1 Beginnen Sie mit funktionierender Software;75
8.4.1.1;4.1.1 Vom Dateneingang zur dauerhaften Datenspeicherung;76
8.4.1.2;4.1.2 Minimaler Vertical Slice;77
8.4.2;4.2 Laufendes Skelett;78
8.4.2.1;4.2.1 Charakterisierungstest;79
8.4.2.2;4.2.2 Arrange, Act, Assert;81
8.4.2.3;4.2.3 Lockerung der statischen Analyse;83
8.4.3;4.3 Von außen nach innen;85
8.4.3.1;4.3.1 JSON entgegennehmen;87
8.4.3.2;4.3.2 Eine Reservierung vornehmen;89
8.4.3.3;4.3.3 Unit-Test;93
8.4.3.4;4.3.4 DTO und Domänenmodell;95
8.4.3.5;4.3.5 Fake-Objekt;98
8.4.3.6;4.3.6 Schnittstelle für das Repository;99
8.4.3.7;4.3.7 Objekte im Repository erstellen;99
8.4.3.8;4.3.8 Abhängigkeiten konfigurieren;101
8.4.4;4.4 Vervollständigen Sie den Slice;102
8.4.4.1;4.4.1 Schema;103
8.4.4.2;4.4.2 SQL-Repository;104
8.4.4.3;4.4.3 Konfiguration mit der Datenbank;106
8.4.4.4;4.4.4 Führen Sie einen Smoke Test durch;107
8.4.4.5;4.4.5 Test der Außengrenze mit einer Fake-Datenbank;108
8.4.5;4.5 Fazit;110
8.5;Kapitel 5: Kapselung;111
8.5.1;5.1 Speichern Sie die Daten;111
8.5.1.1;5.1.1 Prämisse der Priorität der Transformation;111
8.5.1.2;5.1.2 Parametrisierter Test;113
8.5.1.3;5.1.3 DTO ins Domänenmodell kopieren;114
8.5.2;5.2 Validierung;116
8.5.2.1;5.2.1 Ungültige oder fehlende Datumsangaben;117
8.5.2.2;5.2.2 Rot-Grün-Refactor;119
8.5.2.3;5.2.3 Natürliche Zahlen;122
8.5.2.4;5.2.4 Robustheitsgrundsatz;125
8.5.3;5.3 Schutz von Invarianten;128
8.5.3.1;5.3.1 Immer gültig;129
8.5.4;5.4 Fazit;131
8.6;Kapitel 6: Triangulierung;133
8.6.1;6.1 Kurzzeit- und Langzeitgedächtnis;133
8.6.1.1;6.1.1 Legacy Code und Gedächtnis;134
8.6.2;6.2 Kapazität;136
8.6.2.1;6.2.1 Überbuchung;136
8.6.2.2;6.2.2 Advokat des Teufels;139
8.6.2.3;6.2.3 Vorhandene Reservierungen;142
8.6.2.4;6.2.4 Advokat des Teufels und Rot-Grün-Refactor;144
8.6.2.5;6.2.5 Wann haben Sie hinreichend viele Tests?;147
8.6.3;6.3 Fazit;147
8.7;Kapitel 7: Dekomposition;149
8.7.1;7.1 Code Rot;149
8.7.1.1;7.1.1 Schwellenwerte;150
8.7.1.2;7.1.2 Zyklomatische Komplexität;152
8.7.1.3;7.1.3 Die 80/24-Regel;153
8.7.2;7.2 Verständlicher Code;155
8.7.2.1;7.2.1 Hexagonale Blumen;155
8.7.2.2;7.2.2 Kohäsion;157
8.7.2.3;7.2.3 Feature-Neid;161
8.7.2.4;7.2.4 Beim Verschieben verlorengegangen;162
8.7.2.5;7.2.5 Parsen, nicht überprüfen;163
8.7.2.6;7.2.6 Fraktale Architektur;167
8.7.2.7;7.2.7 Variablen zählen;171
8.7.3;7.3 Fazit;171
8.8;Kapitel 8: API-Design;173
8.8.1;8.1 Prinzipien des API-Designs;173
8.8.1.1;8.1.1 Affordanz;173
8.8.1.2;8.1.2 Poka Yoke;175
8.8.1.3;8.1.3 Schreiben Sie für die Leser;177
8.8.1.4;8.1.4 Ziehen Sie sinnvoll benannten Code Kommentaren vor;178
8.8.1.5;8.1.5 Namen ausixen;178
8.8.1.6;8.1.6 Trennung von Befehlen und Abfragen;181
8.8.1.7;8.1.7 Kommunikationshierarchie;184
8.8.2;8.2 Beispiel für ein API-Design;185
8.8.2.1;8.2.1 Maître d’hôtel;186
8.8.2.2;8.2.2 Verwendung eines gekapselten Objekts;188
8.8.2.3;8.2.3 Implementierungsdetails;190
8.8.3;8.3 Fazit;192
8.9;Kapitel 9: Zusammenarbeit;195
8.9.1;9.1 Git;196
8.9.1.1;9.1.1 Commit-Nachrichten;196
8.9.1.2;9.1.2 Continuos Integration;199
8.9.1.3;9.1.3 Kleine Commits;202
8.9.2;9.2 Gemeinsame Eigentümerschaft am Code;204
8.9.2.1;9.2.1 Paarprogrammierung;206
8.9.2.2;9.2.2 Mob-Programmierung;207
8.9.2.3;9.2.3 Verzögerungen durch Code-Reviews;208
8.9.2.4;9.2.4 Ablehnung von Änderungen;210
8.9.2.5;9.2.5 Code-Reviews;211
8.9.2.6;9.2.6 Pull-Requests;213
8.9.3;9.3 Fazit;215
9;Teil II: Nachhaltigkeit;217
9.1;Kapitel 10: Erweiterung des Codes;219
9.1.1;10.1 Feature-Flags;219
9.1.1.1;10.1.1 Kalender-Flag;220
9.1.2;10.2 Das Strangler-Pattern;225
9.1.2.1;10.2.1 Strangler auf Methodenebene;227
9.1.2.2;10.2.2 Strangler auf Klassenebene;230
9.1.3;10.3 Versionierung;234
9.1.3.1;10.3.1 Vorwarnung;235
9.1.4;10.4 Fazit;236
9.2;Kapitel 11: Bearbeiten von Unit-Tests;237
9.2.1;11.1 Refactoring von Unit-Tests;237
9.2.1.1;11.1.1 Änderung des Sicherheitsnetzes;237
9.2.1.2;11.1.2 Hinzufügen von neuem Testcode;238
9.2.1.3;11.1.3 Refactoring von Test- und Produktionscode trennen;241
9.2.2;11.2 Fehlschlagende Tests;246
9.2.3;11.3 Fazit;247
9.3;Kapitel 12: Fehlerbehebung;249
9.3.1;12.1 Verstehen;249
9.3.1.1;12.1.1 Wissenschaftliche Vorgehensweise;249
9.3.1.2;12.1.2 Vereinfachen;250
9.3.1.3;12.1.3 Quietscheentchen-Debugging;252
9.3.2;12.2 Fehler;253
9.3.2.1;12.2.1 Fehler durch Tests reproduzieren;254
9.3.2.2;12.2.2 Langsame Tests;257
9.3.2.3;12.2.3 Nichtdeterministische Fehler;259
9.3.3;12.3 Bisektion;264
9.3.3.1;12.3.1 Bisektion mit Git;264
9.3.4;12.4 Fazit;268
9.4;Kapitel 13: Trennung von Zuständigkeiten;271
9.4.1;13.1 Komposition;271
9.4.1.1;13.1.1 Verschachtelte Komposition;272
9.4.1.2;13.1.2 Sequenzielle Komposition;275
9.4.1.3;13.1.3 Referenzielle Transparenz;277
9.4.2;13.2 Cross-Cutting Concerns;280
9.4.2.1;13.2.1 Logging;281
9.4.2.2;13.2.2 Decorator;281
9.4.2.3;13.2.3 Was protokolliert werden sollte;285
9.4.3;13.3 Fazit;287
9.5;Kapitel 14: Rhythmus;289
9.5.1;14.1 Persönlicher Rhythmus;290
9.5.1.1;14.1.1 Zeiteinteilung;290
9.5.1.2;14.1.2 Pausieren;291
9.5.1.3;14.1.3 Zeit wohlüberlegt nutzen;293
9.5.1.4;14.1.4 Blindschreiben;294
9.5.2;14.2 Team-Rhythmus;295
9.5.2.1;14.2.1 Regelmäßige Aktualisierung der Abhängigkeiten;295
9.5.2.2;14.2.2 Andere Dinge planen;297
9.5.2.3;14.2.3 Gesetz von Conway;297
9.5.3;14.3 Fazit;298
9.6;Kapitel 15: Die üblichen Verdächtigen;299
9.6.1;15.1 Performance;300
9.6.1.1;15.1.1 Altlast;300
9.6.1.2;15.1.2 Verständlichkeit;301
9.6.2;15.2 Security;303
9.6.2.1;15.2.1 STRIDE;304
9.6.2.2;15.2.2 Spoofing;305
9.6.2.3;15.2.3 Tampering;305
9.6.2.4;15.2.4 Repudiation;307
9.6.2.5;15.2.5 Information Disclosure;307
9.6.2.6;15.2.6 Denial of Service;309
9.6.2.7;15.2.7 Elevation of Privilege;310
9.6.3;15.3 Andere Verfahren;311
9.6.3.1;15.3.1 Eigenschaft-basiertes Testen;311
9.6.3.2;15.3.2 Verhaltensbezogene Codeanalyse;316
9.6.4;15.4 Fazit;319
9.7;Kapitel 16: Tour;321
9.7.1;16.1 Navigation;321
9.7.1.1;16.1.1 Das Gesamtbild erkennen;322
9.7.1.2;16.1.2 Organisation der Dateien;326
9.7.1.3;16.1.3 Details aufspüren;328
9.7.2;16.2 Architektur;329
9.7.2.1;16.2.1 Monolith;330
9.7.2.2;16.2.2 Zyklen;331
9.7.3;16.3 Verwendung;334
9.7.3.1;16.3.1 Aus Tests lernen;334
9.7.3.2;16.3.2 Schenken Sie den Tests Beachtung;336
9.7.4;16.4 Fazit;337
10;Anhang A: Liste der Verfahren;339
10.1;A.1 50/72-Regel;339
10.2;A.2 80/24-Regel;339
10.3;A.3 Abhängigkeiten regelmäßig aktualisieren;340
10.4;A.4 Advokat des Teufels;340
10.5;A.5 Arrange, Act, Assert;340
10.6;A.6 Ausnahmen von der Regel begründen;340
10.7;A.7 Bedrohungsmodell;340
10.8;A.8 Bisektion;341
10.9;A.9 Checkliste für eine neue Codebasis;341
10.10;A.10 Code-Reviews;342
10.11;A.11 Decorators für Cross-Cutting Concerns;342
10.12;A.12 Feature-Flag;342
10.13;A.13 Fehler als Tests reproduzieren;342
10.14;A.14 Functional Core, Imperative Shell;342
10.15;A.15 Kommunikationshierarchie;343
10.16;A.16 Namen ausixen;343
10.17;A.17 Parsen, nicht überprüfen;343
10.18;A.18 Robustheitsgrundsatz;344
10.19;A.19 Rot-Grün-Refactor;344
10.20;A.20 Refactoring von Test- und Produktionscode trennen;344
10.21;A.21 Semantische Versionierung;345
10.22;A.22 Slice;345
10.23;A.23 Strangler;345
10.24;A.24 Prämisse der Priorität der Transformation;345
10.25;A.25 Trennung von Befehlen und Abfragen;346
10.26;A.26 X-getriebene Entwicklung;346
10.27;A.27 Zählen der Variablen;346
10.28;A.28 Zyklomatische Komplexität;346
11;Anhang B: Bibliografie;347
12;Stichwortverzeichnis;357

Über Autor(innen)

Mark Seemann ist in der Softwareentwicklung tätig und beschäftigt sich mit funktionaler Programmierung, objektorientierter Entwicklung und Softwareentwicklung im Allgemeinen. Er hat bereits zwei Bücher und zahlreiche Artikel und Blogbeiträge zu verwandten Themen veröffentlicht. Obwohl er hauptsächlich als .NET-Entwickler tätig ist, nutzt er eine große Bandbreite von Technologien als Ressource, einschließlich Haskell und verschiedene Design-Pattern-Bücher.