Code That Fits in Your Head
Description
- Techniken und Konzepte für nachhaltige Softwareentwicklung sowie sauberen und wartbaren Code
- Reduktion von Komplexität, strukturierte Arbeitsabläufe und effiziente Fehlerbehandlung
- Mit 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 funktionieren
- Mit Checklisten mehr Freiheiten schaffen und das Ergebnis verbessern, indem Sie die Fähigkeiten nutzen, über die Sie bereits verfügen
- Code Rot und unnötige Komplexität vermeiden
- Bessere Techniken meistern und neue Routinen bei der Programmierung etablieren
- Neue Wege für effektivere und schnellere Fehlerbehandlung
- Höhere Produktivität in Bezug auf Performance und Sicherheit
Reviews / Votes
»Bücher zur "guten Programmierung" wenden sich oft nur an blutige Einsteiger. Mark Seemann bringt mit "Code That Fits in Your Head" ein Lehrbuch, das sich an Profis richtet. [.] Das Werk unterscheidet sich angenehm von seinen Vorgängern, da es auf aktuelle Technologien setzt. So finden sich im Abschnitt zur Fehlersuche Überlegungen, wie man ein Problem per Gits bisect-Befehl eingrenzen kann. Randthemen wie Performancemanagement und Systemsicherheit bleiben ebenfalls nicht unerwähnt.« (ix Magazin, 09/2022)
More details
Other editions
Additional editions
Person
Content
- Cover
- Titel
- Impressum
- Inhaltsverzeichnis
- Vorwort des Herausgebers der englischen Ausgabe
- Einleitung
- Über den Autor
- Teil I: Beschleunigung
- Kapitel 1: Kunst oder Wissenschaft?
- 1.1 Bau eines Hauses
- 1.1.1 Das Problem mit Projekten
- 1.1.2 Das Problem mit Phasen
- 1.1.3 Abhängigkeiten
- 1.2 Kultivieren eines Gartens
- 1.2.1 Was lässt einen Garten gedeihen?
- 1.3 Der Weg zur Ingenieurswissenschaft
- 1.3.1 Software als Kunsthandwerk
- 1.3.2 Heuristik
- 1.3.3 Ältere Vorstellungen von Software Engineering
- 1.3.4 Fortschritte beim Software Engineering
- 1.4 Fazit
- Kapitel 2: Checklisten
- 2.1 Eine Gedächtnisstütze
- 2.2 Checkliste für eine neue Codebasis
- 2.2.1 Git verwenden
- 2.2.2 Build automatisieren
- 2.2.3 Alle Fehlermeldungen aktivieren
- 2.3 Überprüfungen zu einer vorhandenen Codebasis hinzufügen
- 2.3.1 Schrittweise Verbesserungen
- 2.3.2 Hacken Sie Ihre Organisation
- 2.4 Fazit
- Kapitel 3: Komplexität in den Griff bekommen
- 3.1 Ziel
- 3.1.1 Nachhaltigkeit
- 3.1.2 Nutzwert
- 3.2 Warum Programmieren schwierig ist
- 3.2.1 Die Gehirn-Metapher
- 3.2.2 Code wird häufiger gelesen als geschrieben
- 3.2.3 Verständlichkeit
- 3.2.4 Geistige Arbeit
- 3.3 Software Engineering
- 3.3.1 Beziehung zur Informatik
- 3.3.2 Menschenfreundlicher Code
- 3.4 Fazit
- Kapitel 4: Vertical Slice
- 4.1 Beginnen Sie mit funktionierender Software
- 4.1.1 Vom Dateneingang zur dauerhaften Datenspeicherung
- 4.1.2 Minimaler Vertical Slice
- 4.2 Laufendes Skelett
- 4.2.1 Charakterisierungstest
- 4.2.2 Arrange, Act, Assert
- 4.2.3 Lockerung der statischen Analyse
- 4.3 Von außen nach innen
- 4.3.1 JSON entgegennehmen
- 4.3.2 Eine Reservierung vornehmen
- 4.3.3 Unit-Test
- 4.3.4 DTO und Domänenmodell
- 4.3.5 Fake-Objekt
- 4.3.6 Schnittstelle für das Repository
- 4.3.7 Objekte im Repository erstellen
- 4.3.8 Abhängigkeiten konfigurieren
- 4.4 Vervollständigen Sie den Slice
- 4.4.1 Schema
- 4.4.2 SQL-Repository
- 4.4.3 Konfiguration mit der Datenbank
- 4.4.4 Führen Sie einen Smoke Test durch
- 4.4.5 Test der Außengrenze mit einer Fake-Datenbank
- 4.5 Fazit
- Kapitel 5: Kapselung
- 5.1 Speichern Sie die Daten
- 5.1.1 Prämisse der Priorität der Transformation
- 5.1.2 Parametrisierter Test
- 5.1.3 DTO ins Domänenmodell kopieren
- 5.2 Validierung
- 5.2.1 Ungültige oder fehlende Datumsangaben
- 5.2.2 Rot-Grün-Refactor
- 5.2.3 Natürliche Zahlen
- 5.2.4 Robustheitsgrundsatz
- 5.3 Schutz von Invarianten
- 5.3.1 Immer gültig
- 5.4 Fazit
- Kapitel 6: Triangulierung
- 6.1 Kurzzeit- und Langzeitgedächtnis
- 6.1.1 Legacy Code und Gedächtnis
- 6.2 Kapazität
- 6.2.1 Überbuchung
- 6.2.2 Advokat des Teufels
- 6.2.3 Vorhandene Reservierungen
- 6.2.4 Advokat des Teufels und Rot-Grün-Refactor
- 6.2.5 Wann haben Sie hinreichend viele Tests?
- 6.3 Fazit
- Kapitel 7: Dekomposition
- 7.1 Code Rot
- 7.1.1 Schwellenwerte
- 7.1.2 Zyklomatische Komplexität
- 7.1.3 Die 80/24-Regel
- 7.2 Verständlicher Code
- 7.2.1 Hexagonale Blumen
- 7.2.2 Kohäsion
- 7.2.3 Feature-Neid
- 7.2.4 Beim Verschieben verlorengegangen
- 7.2.5 Parsen, nicht überprüfen
- 7.2.6 Fraktale Architektur
- 7.2.7 Variablen zählen
- 7.3 Fazit
- Kapitel 8: API-Design
- 8.1 Prinzipien des API-Designs
- 8.1.1 Affordanz
- 8.1.2 Poka Yoke
- 8.1.3 Schreiben Sie für die Leser
- 8.1.4 Ziehen Sie sinnvoll benannten Code Kommentaren vor
- 8.1.5 Namen ausixen
- 8.1.6 Trennung von Befehlen und Abfragen
- 8.1.7 Kommunikationshierarchie
- 8.2 Beispiel für ein API-Design
- 8.2.1 Maître d'hôtel
- 8.2.2 Verwendung eines gekapselten Objekts
- 8.2.3 Implementierungsdetails
- 8.3 Fazit
- Kapitel 9: Zusammenarbeit
- 9.1 Git
- 9.1.1 Commit-Nachrichten
- 9.1.2 Continuos Integration
- 9.1.3 Kleine Commits
- 9.2 Gemeinsame Eigentümerschaft am Code
- 9.2.1 Paarprogrammierung
- 9.2.2 Mob-Programmierung
- 9.2.3 Verzögerungen durch Code-Reviews
- 9.2.4 Ablehnung von Änderungen
- 9.2.5 Code-Reviews
- 9.2.6 Pull-Requests
- 9.3 Fazit
- Teil II: Nachhaltigkeit
- Kapitel 10: Erweiterung des Codes
- 10.1 Feature-Flags
- 10.1.1 Kalender-Flag
- 10.2 Das Strangler-Pattern
- 10.2.1 Strangler auf Methodenebene
- 10.2.2 Strangler auf Klassenebene
- 10.3 Versionierung
- 10.3.1 Vorwarnung
- 10.4 Fazit
- Kapitel 11: Bearbeiten von Unit-Tests
- 11.1 Refactoring von Unit-Tests
- 11.1.1 Änderung des Sicherheitsnetzes
- 11.1.2 Hinzufügen von neuem Testcode
- 11.1.3 Refactoring von Test- und Produktionscode trennen
- 11.2 Fehlschlagende Tests
- 11.3 Fazit
- Kapitel 12: Fehlerbehebung
- 12.1 Verstehen
- 12.1.1 Wissenschaftliche Vorgehensweise
- 12.1.2 Vereinfachen
- 12.1.3 Quietscheentchen-Debugging
- 12.2 Fehler
- 12.2.1 Fehler durch Tests reproduzieren
- 12.2.2 Langsame Tests
- 12.2.3 Nichtdeterministische Fehler
- 12.3 Bisektion
- 12.3.1 Bisektion mit Git
- 12.4 Fazit
- Kapitel 13: Trennung von Zuständigkeiten
- 13.1 Komposition
- 13.1.1 Verschachtelte Komposition
- 13.1.2 Sequenzielle Komposition
- 13.1.3 Referenzielle Transparenz
- 13.2 Cross-Cutting Concerns
- 13.2.1 Logging
- 13.2.2 Decorator
- 13.2.3 Was protokolliert werden sollte
- 13.3 Fazit
- Kapitel 14: Rhythmus
- 14.1 Persönlicher Rhythmus
- 14.1.1 Zeiteinteilung
- 14.1.2 Pausieren
- 14.1.3 Zeit wohlüberlegt nutzen
- 14.1.4 Blindschreiben
- 14.2 Team-Rhythmus
- 14.2.1 Regelmäßige Aktualisierung der Abhängigkeiten
- 14.2.2 Andere Dinge planen
- 14.2.3 Gesetz von Conway
- 14.3 Fazit
- Kapitel 15: Die üblichen Verdächtigen
- 15.1 Performance
- 15.1.1 Altlast
- 15.1.2 Verständlichkeit
- 15.2 Security
- 15.2.1 STRIDE
- 15.2.2 Spoofing
- 15.2.3 Tampering
- 15.2.4 Repudiation
- 15.2.5 Information Disclosure
- 15.2.6 Denial of Service
- 15.2.7 Elevation of Privilege
- 15.3 Andere Verfahren
- 15.3.1 Eigenschaft-basiertes Testen
- 15.3.2 Verhaltensbezogene Codeanalyse
- 15.4 Fazit
- Kapitel 16: Tour
- 16.1 Navigation
- 16.1.1 Das Gesamtbild erkennen
- 16.1.2 Organisation der Dateien
- 16.1.3 Details aufspüren
- 16.2 Architektur
- 16.2.1 Monolith
- 16.2.2 Zyklen
- 16.3 Verwendung
- 16.3.1 Aus Tests lernen
- 16.3.2 Schenken Sie den Tests Beachtung
- 16.4 Fazit
- Anhang A: Liste der Verfahren
- A.1 50/72-Regel
- A.2 80/24-Regel
- A.3 Abhängigkeiten regelmäßig aktualisieren
- A.4 Advokat des Teufels
- A.5 Arrange, Act, Assert
- A.6 Ausnahmen von der Regel begründen
- A.7 Bedrohungsmodell
- A.8 Bisektion
- A.9 Checkliste für eine neue Codebasis
- A.10 Code-Reviews
- A.11 Decorators für Cross-Cutting Concerns
- A.12 Feature-Flag
- A.13 Fehler als Tests reproduzieren
- A.14 Functional Core, Imperative Shell
- A.15 Kommunikationshierarchie
- A.16 Namen ausixen
- A.17 Parsen, nicht überprüfen
- A.18 Robustheitsgrundsatz
- A.19 Rot-Grün-Refactor
- A.20 Refactoring von Test- und Produktionscode trennen
- A.21 Semantische Versionierung
- A.22 Slice
- A.23 Strangler
- A.24 Prämisse der Priorität der Transformation
- A.25 Trennung von Befehlen und Abfragen
- A.26 X-getriebene Entwicklung
- A.27 Zählen der Variablen
- A.28 Zyklomatische Komplexität
- Anhang B: Bibliografie
- Stichwortverzeichnis
