Beschreibung / Abstract

Beschreibung

Inhaltsverzeichnis

• BEGINN
• Inhalt
• Kapitel 1: Einführung (es geht immer um Komplexität)
• Wie Sie dieses Buch einsetzen
• Kapitel 2: Die Natur der Komplexität
• Definition der Komplexität
• Symptome der Komplexität
• Ursachen für Komplexität
• Komplexität ist inkrementell
• Zusammenfassung
• Kapitel 3: Funktionierender Code reicht nicht aus (strategische versus taktische Programmierung)
• Taktische Programmierung
• Strategische Programmierung
• Wie viel soll ich investieren?
• Start-ups und Investitionen
• Zusammenfassung
• Kapitel 4: Module sollten tief sein
• Modulares Design
• Was ist eine Schnittstelle?
• Abstraktionen
• Tiefe Module
• Flache Module
• Klassizitis
• Beispiele: Java und Unix-I/O
• Zusammenfassung
• Kapitel 5: Information Hiding (und Lecks)
• Information Hiding
• Informationslecks
• Zeitliche Dekomposition
• Beispiel: HTTP-Server
• Beispiel: Zu viele Klassen
• Beispiel: HTTP-Parameter-Handling
• Beispiel: Standardwerte in HTTP-Responses
• Information Hiding in einer Klasse
• Wann Sie zu weit gehen
• Zusammenfassung
• Kapitel 6: Vielseitige Module sind tiefer
• Gestalten Sie Klassen halbwegs vielseitig
• Beispiel: Text für einen Editor speichern
• Eine vielseitigere API
• Vielseitigkeit führt zu besserem Information Hiding
• Fragen, die Sie sich stellen sollten
• Spezialisierung nach oben (und unten!) schieben
• Beispiel: Undo-Mechanismus für den Editor
• Spezialfälle wegdesignen
• Zusammenfassung
• Kapitel 7: Verschiedene Schichten, verschiedene Abstraktionen
• Pass-Through-Methoden
• Wann ist es in Ordnung, Schnittstellen doppelt zu haben?
• Das Decorator-Design-Pattern
• Schnittstelle versus Implementierung
• Pass-Through-Variablen
• Zusammenfassung
• Kapitel 8: Komplexität nach unten ziehen
• Beispiel: Texteditor-Klasse
• Beispiel: Konfigurationsparameter
• Wann Sie zu weit gehen
• Zusammenfassung
• Kapitel 9: Zusammen oder getrennt?
• Zusammenbringen bei gemeinsamen Informationen
• Zusammenbringen, um die Schnittstelle zu vereinfachen
• Zusammenbringen, um doppelten Code zu vermeiden
• Trennen von allgemeinem und speziellem Code
• Beispiel: Einfügecursor und Auswahl
• Beispiel: Getrennte Klasse zum Loggen
• Methoden aufteilen und zusammenführen
• Eine andere Meinung: Clean Code
• Zusammenfassung
• Kapitel 10: Definieren Sie die Existenz von Fehlern weg
• Warum Exceptions zur Komplexität beitragen
• Zu viele Exceptions
• Die Existenz von Fehlern wegdefinieren
• Beispiel: Datei löschen in Windows
• Beispiel: substring-Methode in Java
• Exceptions maskieren
• Aggregieren von Exceptions
• Einfach abstürzen?
• Wann Sie zu weit gehen
• Zusammenfassung
• Kapitel 11: Designen Sie zweimal
• Kapitel 12: Warum Kommentare schreiben? – Die vier Ausreden
• Guter Code dokumentiert sich selbst
• Ich habe keine Zeit, Kommentare zu schreiben
• Kommentare veralten und sind dann irreführend
• Die Kommentare, die ich gesehen habe, sind alle nutzlos
• Die Vorteile gut geschriebener Kommentare
• Eine andere Meinung: Kommentare sind Fehler
• Kapitel 13: Kommentare sollten Dinge beschreiben, die im Code nicht offensichtlich sind
• Konventionen
• Wiederholen Sie nicht den Code
• Kommentare auf niedrigerer Ebene sorgen für Präzision
• Kommentare auf höherer Ebene verbessern die Intuition
• Schnittstellendokumentation
• Implementierungskommentare: was und warum, nicht wie
• Modulübergreifende Designentscheidungen
• Zusammenfassung
• Antworten auf die Fragen aus dem Abschnitt »Schnittstellendokumentation« auf Seite 123
• Kapitel 14: Namen auswählen
• Beispiel: Schlechte Namen führen zu Fehlern
• Ein Bild schaffen
• Namen sollten präzise sein
• Namen konsistent einsetzen
• Vermeiden Sie überflüssige Wörter
• Eine andere Meinung: Go Style Guide
• Zusammenfassung
• Kapitel 15: Erst die Kommentare schreiben (nutzen Sie Kommentare als Teil des Designprozesses)
• Aufgeschobene Kommentare sind schlechte Kommentare
• Erst die Kommentare schreiben
• Kommentare sind ein Designwerkzeug
• Frühes Kommentieren macht Spaß
• Sind frühe Kommentare teuer?
• Zusammenfassung
• Kapitel 16: Bestehenden Code anpassen
• Bleiben Sie strategisch
• Kommentare pflegen: Halten Sie die Kommentare nahe am Code
• Kommentare gehören in den Code, nicht in das Commit-Log
• Kommentare pflegen: Vermeiden Sie Duplikate
• Kommentare pflegen: Schauen Sie auf die Diffs
• Kommentare auf höherer Ebene lassen sich leichter pflegen
• Kapitel 17: Konsistenz
• Beispiele für Konsistenz
• Konsistenz sicherstellen
• Wann Sie zu weit gehen
• Zusammenfassung
• Kapitel 18: Code sollte offensichtlich sein
• Dinge, die Code offensichtlicher machen
• Dinge, die Code weniger offensichtlich machen
• Zusammenfassung
• Kapitel 19: Softwaretrends
• Objektorientierte Programmierung und Vererbung
• Agile Entwicklung
• Unit Tests
• Test-Driven Development
• Design Patterns
• Getter und Setter
• Zusammenfassung
• Kapitel 20: Performance
• Wie man über Performance nachdenkt
• Vor (und nach) dem Ändern messen
• Rund um den kritischen Pfad designen
• Ein Beispiel: RAMCloud-Buffer
• Zusammenfassung
• Kapitel 21: Entscheiden, was wichtig ist
• Wie entscheidet man, was wichtig ist?
• Lassen Sie möglichst wenig wichtig sein
• Wie Sie wichtige Dinge hervorheben
• Fehler
• Denken Sie umfassender
• Kapitel 22: Zusammenfassung
• Index