Code That Fits in Your Head Heuristiken für die Softwareentwicklung. Komplexität reduzieren | Legacy Code beherrschen | Performance optimieren
Techniken und Konzepte f|r nachhaltige Softwareentwicklung sowie sauberen und wartbaren Code Reduktion von Komplexitt̃, strukturierte Arbeitsablũfe und effiziente Fehlerbehandlung Mit Ausz|gen aus einem vollstñdigen Beispielprojekt inklusive Code zum Download Mark Seemann ist daf|r bekannt, komple...
| Autor principal: | |
|---|---|
| Formato: | Libro electrónico |
| Idioma: | Alemán |
| Publicado: |
Frechen :
mitp
2022.
|
| Edición: | 1st ed |
| Colección: | Robert C. Martin series.
|
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009670621806719 |
Tabla de Contenidos:
- Intro
- Stimmen zum Buch
- Code That Fits in Your Head
- Impressum
- Vorwort des Herausgebers der englischen Ausgabe
- Einleitung
- Wer dieses Buch lesen sollte
- Voraussetzungen
- Ein Hinweis für Softwarearchitekten
- Aufbau des Buchs
- Über den Codestil
- var verwenden oder var nicht verwenden
- Code-Listings
- Hinweis zur Bibliografie
- Eigene Zitate
- Danksagung
- Ü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.
