Clean Code

Name: Clean Code | Refactoring, Patterns, Testen und Techniken für sauberen Code. Deutsche Ausgabe
Brand: MITP
Price: 49.99 EUR
Availability: OnlineOnly

Refactoring, Patterns, Testen und Techniken für sauberen Code. Deutsche Ausgabe

Robert C. Martin(Author)

MITP (Publisher)

2nd Edition

Published on 16. March 2026

752 pages

E-Book

ePUB with digital watermarking

System requirements

978-3-7475-1134-3 (ISBN)

€49.99incl. 7% vat

System requirements

for ePUB with digital watermarking

E-Book Single Licence

Available for download

Description

Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.

Alles über E-Books, Kopierschutz & Dateiformate finden Sie in unserem Info- & Hilfebereich.

Sauberen, wartbaren und langfristig stabilen Code entwickeln - nach den Prinzipien von Robert C. Martin (Uncle Bob)

Für Softwareentwickler und Software Engineers , die ihre Codequalität systematisch verbessern möchten
Bewährte Best Practices für sauberen, flexiblen und wartbaren Code verständlich erklärt
Fallstudien, Heuristiken und Code Smells helfen, problematischen Code zu erkennen und gezielt zu refaktorieren
Zentrale Designprinzipien wie SOLID sowie Techniken für Funktionen, Klassen, Tests und Fehlerbehandlung
Fokus auf professionelle Entwicklungspraktiken und verantwortungsvolle Softwareentwicklung

More details

Other editions

Persons

Content

Titelbild
Titelseite
Impressum
Inhaltsverzeichnis
Vorwort
Einleitung
Ein Hinweis zu älteren Kapiteln
Wie dieses Buch aufgebaut ist
Einleitung (aus längst vergangenen Zeiten)
Über den Autor
Kapitel 1: Sauberer Code
1.1 Code, Code und nochmals Code
1.2 Schlechter Code
1.2.1 Einstellung
1.2.2 Das grundlegende Problem
1.3 Sauberen Code schreiben - eine Kunst?
1.3.1 Was ist sauberer Code?
1.4 Das große Ganze
1.4.1 Was bringt uns sauberer Code?
1.4.2 Produktivität
1.4.3 Lebensqualität
1.5 Wir lesen mehr, als wir schreiben
1.6 Die Pfadfinder-Regel
Teil I: Code
Kapitel 2: Halten Sie Ihren Code sauber!
2.1 Der Bereinigungsvorgang
2.2 Zusammenfassung
2.3 Postskriptum: Bob aus der Zukunft spielt mit Grok 3
2.4 Zusammenfassung des Postskriptums
Kapitel 3: Grundlegende Prinzipien
3.1 Klein, aussagekräftig benannt, strukturiert und sortiert
3.1.1 Funktionen
3.2 Ein aussagekräftigeres Beispiel
3.2.1 Unabhängige Auslieferbarkeit
3.3 Abschließende Bemerkungen
Kapitel 4: Aussagekräftige Namen
4.1 Zweckbeschreibende Namen wählen
4.1.1 Ein Namenssystem aufbauen
4.1.2 Fehlinformationen vermeiden
4.1.3 Unterschiede deutlich machen
4.1.4 Aussprechbare Namen verwenden
4.1.5 Suchbare Namen verwenden
4.1.6 Namen von sinnvoller Länge verwenden
4.1.7 Codierungen vermeiden
4.1.8 Passende Wortarten verwenden
4.1.9 Schlüsselwort-Parameter beachten
4.1.10 Keine lustig gemeinten Namen verwenden
4.1.11 Ein Wort pro Konzept wählen
4.1.12 Namen der Lösungsdomäne verwenden
4.1.13 Namen der Problemdomäne verwenden
4.1.14 Sinnstiftenden Kontext hinzufügen
4.1.15 Keinen überflüssigen Kontext hinzufügen
4.2 Abschließende Worte
Kapitel 5: Kommentare
5.1 Unser Scheitern kaschieren
5.1.1 Ausgeblendete oder verborgene Kommentare
5.1.2 Lügende Kommentare
5.1.3 Insider-Kommentare
5.1.4 Kommentare sind kein Ersatz für guten Code
5.1.5 Erklären Sie Ihre Intention durch den Code
5.2 Gute Kommentare
5.2.1 Juristische Kommentare
5.2.2 Informierende Kommentare
5.2.3 Erklärung der Intention
5.2.4 Klarstellungen
5.2.5 Warnungen vor Konsequenzen
5.2.6 Verstärkung
5.2.7 Javadocs (und Verwandte) in öffentlichen APIs
5.3 Schlechte Kommentare
5.3.1 Selbstgespräche
5.3.2 Redundante Kommentare
5.3.3 Irreführende Kommentare
5.3.4 Redundanz und Ungenauigkeit
5.3.5 Vorgeschriebene Kommentare
5.3.6 Tagebuch-Kommentare
5.3.7 Geschwätz
5.3.8 Grauenvolles Geschwätz
5.3.9 TODO-Kommentare
5.3.10 Funktionen oder Variablen anstelle von Kommentaren verwenden
5.3.11 Positionsbezeichner
5.3.12 Zuschreibungen und Nebenbemerkungen
5.3.13 Auskommentierter Code
5.3.14 HTML-Kommentare
5.3.15 Nicht lokale Informationen
5.3.16 Zu viele Informationen
5.3.17 Unklarer Zusammenhang
5.3.18 Funktionskopf-Kommentare
5.3.19 Javadocs in nicht öffentlichem Code
5.3.20 Beispiel
5.4 Zusammenfassung
Kapitel 6: Formatierung
6.1 Der Zweck der Formatierung
6.2 Vertikale Formatierung
6.2.1 Vertikaler Weißraum zwischen Konzepten
6.2.2 Vertikale Dichte
6.2.3 Vertikaler Abstand
6.2.4 Variablendeklarationen
6.2.5 Abhängige Funktionen
6.2.6 Konzeptionelle Affinität
6.3 Horizontale Formatierung
6.3.1 Horizontaler Weißraum und Dichte
6.3.2 Horizontale Ausrichtung
6.3.3 Einrückung
6.3.4 Einrückungsregeln brechen
6.4 Team-Regeln
6.5 Uncle Bobs Formatierungsregeln
Kapitel 7: Saubere Funktionen
7.1 Klein!
7.1.1 Wohlgeschriebene Prosa
7.1.2 Eine Abstraktionsebene pro Funktion
7.2 Code von oben nach unten lesen: Stepdown-Regel
7.2.1 Kuddelmuddel
7.3 Switch-Anweisungen
7.4 Saubere Funktionen: Eine genauere Betrachtung
7.4.1 Kontextbezogen
7.4.2 Benennbar
7.4.3 Isoliert
7.4.4 Homogen
7.4.5 Rein
7.5 Zusammenfassung
Kapitel 8: Heuristiken für Funktionen
8.1 Funktionsargumente
8.1.1 Variadische Argumente
8.1.2 Mehr als drei Argumente?
8.1.3 Schlüsselwort-Argumente
8.1.4 Flag-Argumente
8.1.5 Output-Argumente
8.1.6 Fehlercodes
8.2 Anweisung und Abfrage trennen
8.3 Exceptions sind besser als Fehlercodes
8.3.1 Auf eigene Gefahr!
8.3.2 try/catch-Blöcke extrahieren
8.3.3 Fehler-Handling ist eine Aufgabe
8.3.4 Der Abhängigkeitsmagnet von Fehlercodes
8.4 DRY: Don't Repeat Yourself
8.4.1 Einfacher wiederholter Code
8.4.2 Ähnlicher Code
8.4.3 Schleifen-Duplizierung
8.4.4 Zufällige und essenzielle Duplizierung
8.5 Nebeneffekte
8.5.1 Wir sind nicht gut darin
8.5.2 Funktionale Programmiersprachen
8.5.3 Objektorientierte Sprachen
8.6 Strukturierte Programmierung
8.6.1 Sequenzen
8.6.2 Selektionen
8.6.3 Iterationen
8.7 Wer soll sich das alles merken?
8.8 Zusammenfassung
Kapitel 9: Die saubere Methode
9.1 Mach es richtig
9.2 Beispiel
9.2.1 Design und Architektur berücksichtigen
9.3 Zusammenfassung
Kapitel 10: Eine Aufgabe
10.1 Refactoring per Extract-Methode
10.1.1 Widerstand ist zwecklos!
10.2 Was sind große Funktionen überhaupt?
10.3 Extraktion und Klassen
10.4 Zusammenfassung
Kapitel 11: Eine Frage des Respekts
11.1 Die Zeitungsmetapher
11.1.1 Respektvoll schreiben
11.2 Die Stepdown-Regel: »Hello again«
11.3 Die Abstraktions-Achterbahn
11.4 Schreiben und Lesen funktionieren unterschiedlich
Kapitel 12: Objekte und Datenstrukturen
12.1 Was ist ein Objekt?
12.2 Datenabstraktion
12.3 Daten/Objekt-Antisymmetrie
12.4 Das Gesetz von Demeter
12.4.1 Train Wreck
12.4.2 Hybride
12.4.3 Struktur verbergen
12.5 Datentransfer-Objekte
12.5.1 Das objekt-relationale »Impedance Mismatch«
12.5.2 Objekte und Datenstrukturen verwenden
12.5.3 switch-Anweisungen
12.5.4 Die objektorientierte Lösung
12.5.5 Ruhig, Brauner
12.6 Kompromiss zwischen objektorientierten und prozeduralen Konzepten
12.7 Aber wie sieht es mit der Geschwindigkeit aus?
12.8 Zusammenfassung
Kapitel 13: Saubere Klassen
13.1 Klassen und Module im Vergleich zu Dateien
13.2 Was sollte eine Klasse enthalten?
13.2.1 Klassendesign auf den Punkt gebracht
13.2.2 Heuristiken und Charakteristiken
13.2.3 Wann ist eine Klasse zu groß?
13.2.4 Policys im Code
13.2.5 Wo sich Gründe für Veränderungen verbergen
13.2.6 Die Lösung
13.2.7 Eine übermäßig offene Implementierung
13.2.8 Jetzt handeln oder abwarten?
13.2.9 Und was jetzt?
13.3 Geschlossene, kohäsive Single-Responsibility-Klassen
13.3.1 Wenn sich Policys ändern
13.3.2 Ist das Overengineering?
13.3.3 Einfacheres Testen
13.4 Bühne frei für die KI
13.4.1 Fehler sind unvermeidlich
Kapitel 14: Testdisziplinen
14.1 Disziplin 1: Test-Driven Development (TDD)
14.1.1 Die drei Gesetze des TDD
14.2 Disziplin 2: Test && Commit || Revert (TCR)
14.3 Disziplin 3: Small Bundles
14.4 Design
14.5 Disziplin
14.5.1 Lästig, langweilig und langsam
14.5.2 Debuggen
14.5.3 Dokumentation
14.5.4 Zuverlässigkeit
14.5.5 Design
14.5.6 Reprise
14.5.7 Engelchen und Teufelchen
14.5.8 Das Teufelchen mundtot machen
14.5.9 Komplikationen und Schlupflöcher
14.5.10 Kosten und Konsequenzen
14.6 Tests sauber halten
14.7 Tests ermöglichen die »-keiten«
Kapitel 15: Saubere Tests
15.1 Domänenspezifische Testsprache
15.1.1 Zusammengesetzte Assertions
15.1.2 Zusammengesetzte Testergebnisse
15.1.3 Ein Doppelstandard
15.1.4 Single-Assert-Regel
15.1.5 Single-Act-Regel
15.2 F.I.R.S.T.
15.2.1 Fast (Schnell)
15.2.2 Isolated (Isoliert)
15.2.3 Repeatable (Wiederholbar)
15.2.4 Self-Validating (Selbstvalidierend)
15.2.5 Timely (Zeitnah)
15.3 Testdesign
15.4 Zusammenfassung
Kapitel 16: Akzeptanztests
16.1 Die Akzeptanztest-Disziplin
16.1.1 Die Disziplin
16.1.2 Kontinuierlicher Build
16.2 Zusammenfassung
Kapitel 17: KI, LLMs und wie sie alle heißen
17.1 Programmieren per Prompt
17.1.1 In den Kinderschuhen
17.1.2 Wilde wissenschaftliche Vermutung
17.2 Zusammenfassung
Teil II: Design
Kapitel 18: Einfaches Design
18.1 YAGNI
18.2 Abgedeckt durch Tests
18.2.1 Ein asymptotisches Ziel
18.2.2 Design?
18.3 Aussagekraft maximieren
18.3.1 Die zugrunde liegende Abstraktion
18.3.2 Tests: Die zweite Hälfte des Problems
18.4 Duplizierung minimieren
18.4.1 Zufällige Duplizierung
18.4.2 Größe minimieren
18.4.3 Einfaches Design
Kapitel 19: Die SOLID-Prinzipien
19.1 SRP: Das Single-Responsibility-Prinzip
19.1.1 Zufällige Duplizierung
19.1.2 Lösungen
19.1.3 Höhere Ebenen
19.2 OCP: Das Open-Closed-Prinzip
19.2.1 Ein Gedankenexperiment
19.2.2 Richtungssteuerung
19.2.3 Information Hiding
19.2.4 Zusammenfassung
19.3 LSP: Das Liskov'sche Substitutionsprinzip
19.3.1 LSP und Softwaredesign
19.3.2 Taxi-Aggregator
19.4 ISP: Das Interface-Segregation-Prinzip
19.4.1 ISP und Programmiersprachen
19.4.2 ISP und Softwaredesign
19.5 DIP: Das Dependency-Inversion-Prinzip
19.5.1 Stabile Abstraktionen
19.5.2 Factorys
19.5.3 Konkrete Komponenten
Kapitel 20: Komponentenprinzipien
20.1 Komponenten
20.2 Eine kurze Historie der Komponenten
20.2.1 Relokatierbarkeit
20.2.2 Linker
20.3 Komponentenkohäsion
20.3.1 Das Reuse/Release-Equivalence-Prinzip (REP)
20.3.2 Das Common-Closure-Prinzip (CCP)
20.3.3 Das Common-Reuse-Prinzip (CRP)
20.3.4 Das Spannungsdiagramm für die Komponentenkohäsion
20.3.5 Zusammenfassung
20.4 Komponentenkopplung
20.4.1 Das Acyclic-Dependencies-Prinzip (ADP)
20.4.2 Das Stable-Dependencies-Prinzip (SDP)
20.4.3 Das Stable-Abstractions-Prinzip (SAP)
20.5 Zusammenfassung
Kapitel 21: Kontinuierliches Design
21.1 Kontinuierliche Veränderung
21.2 Kontinuierliches Design
21.3 Die vier K des kontinuierlichen Designs
21.3.1 Klarheit
21.3.2 Kürze
21.3.3 Konfirmierung
21.3.4 Kohäsion
21.4 Wann sind wir außerdem noch Designer?
21.4.1 Vorabdesign
21.4.2 Auf die Plätze!
21.4.3 Fertig!
21.4.4 Los!
Kapitel 22: Nebenläufigkeit
22.1 Warum Nebenläufigkeit?
22.1.1 Mythen und falsche Vorstellungen
22.1.2 Herausforderungen
22.2 Prinzipien zur Absicherung von Nebenläufigkeit
22.2.1 Single-Responsibility-Prinzip
22.2.2 Korollar: Beschränken Sie den Gültigkeitsbereich von Daten
22.2.3 Korollar: Arbeiten Sie mit Kopien der Daten
22.2.4 Korollar: Threads sollten voneinander so unabhängig wie möglich sein
22.2.5 Lernen Sie Ihre Programmiersprache und Bibliothek kennen
22.2.6 Threadsichere Collections
22.3 Lernen Sie Ihre Ausführungsmodelle kennen
22.3.1 Erzeuger-Verbraucher
22.3.2 Leser-Schreiber
22.3.3 Philosophenproblem
22.4 Achten Sie auf Abhängigkeiten zwischen synchronisierten Methoden
22.5 Halten Sie synchronisierte Abschnitte klein
22.6 Korrekten Startup- und Shutdown-Code zu schreiben, ist schwer
22.7 Threaded-Code testen
22.7.1 Behandeln Sie gelegentlich auftretende Fehler als potenzielle Threading-Probleme
22.7.2 Bringen Sie erst den Nonthreaded-Code zum Laufen
22.7.3 Machen Sie Ihren Threaded-Code austauschbar
22.7.4 Schreiben Sie anpassbaren Threaded-Code
22.7.5 Den Code mit mehr Threads als Prozessoren ausführen
22.7.6 Den Code auf verschiedenen Plattformen ausführen
22.7.7 Code instrumentieren, um Fehler zu provozieren
22.8 Nachtrag im Jahr 2025: Neue Erkenntnisse aus der Praxis
22.8.1 Datenintegrität
22.9 Zusammenfassung
Teil III: Architektur
Kapitel 23: Die Geschichte zweier Werte
23.1 Optionen offenhalten
Kapitel 24: Unabhängigkeit
24.1 Use Cases
24.2 Betrieb
24.3 Entwicklung
24.4 Deployment
24.5 Optionen offenhalten
Kapitel 25: Architekturgrenzen
25.1 Welche Grenzen sollten Sie ziehen - und wann?
25.2 Plugin-Architektur
25.3 Fallstudie: FitNesse
25.4 Zusammenfassung
Kapitel 26: Saubere Grenzen
26.1 IoT-Framework vom Drittanbieter: Jede Menge Grenzen
26.2 Grenze zwischen UI und Anwendung
26.2.1 SOLID und hexagonale Architektur
26.2.2 Grenzen erforschen und kennenlernen
26.2.3 Code verwenden, der noch nicht existiert
26.3 Saubere Grenzen
Kapitel 27: Saubere Architektur
27.1 Die Abhängigkeitsregel
27.1.1 Entitäten
27.1.2 Use Cases
27.1.3 Schnittstellenadapter
27.1.4 Frameworks und Treiber
27.1.5 Nur vier Kreise?
27.1.6 Grenzen überschreiten
27.1.7 Welche Daten überschreiten die Grenzen?
27.2 Ein typisches Beispiel
27.3 Zusammenfassung
Teil IV: Craftsmanship
IV.1 »Eine große Anzahl«
IV.2 Acht Jahrzehnte
IV.2.1 Nerds und Helden
IV.2.2 Berühmt und berüchtigt
IV.2.3 Vorbilder und Schurken
IV.2.4 Wir regieren die Welt
IV.2.5 Katastrophen
IV.3 Der Eid
Kapitel 28: Schaden
28.1 Gesellschaftlicher Schaden
28.2 Funktionsbeeinträchtigungen
28.3 Schädigung der Struktur
28.4 Soft
28.5 Tests
Kapitel 29: Weder im Verhalten noch in der Struktur fehlerhaft
29.1 Mach es richtig
29.1.1 Was ist gute Struktur?
29.1.2 Eisenhower-Matrix
29.2 Programmierer sind Stakeholder
29.3 Ihr Bestes geben
Kapitel 30: Reproduzierbarer Beweis
30.1 Dijkstra
30.1.1 Beweis der Korrektheit
30.2 Strukturierte Programmierung
30.3 Funktionale Dekomposition
30.4 Test-Driven Development und mehr
Kapitel 31: Kurze Zyklen
31.1 Die Geschichte der Versionsverwaltung
31.1.1 Lochkarten
31.1.2 Kontinuierliche Integration
31.1.3 Kurze Zyklen
31.2 Kontinuierliche Integration
31.3 Branches versus Toggles
31.4 Kontinuierliches Deployment
31.5 Kontinuierlicher Build
Kapitel 32: Unablässliche Verbesserung
32.1 Testabdeckung
32.2 Mutationstests
32.3 Semantische Stabilität
32.4 Aufräumen
32.5 Kreationen
Kapitel 33: Hohe Produktivität beibehalten
33.1 Viskosität
33.1.1 Build erstellen
33.1.2 Testen
33.1.3 Debugging
33.1.4 Deployment
33.2 Ablenkungen
33.2.1 Meetings
33.2.2 Musik
33.2.3 Stimmung
33.2.4 Der Flow
33.3 Zeitmanagement
Kapitel 34: Teamarbeit
34.1 Kollaborative Programmierung
34.2 Offenes/virtuelles Büro
Kapitel 35: Ehrliche und faire Schätzungen
35.1 Lügen
35.2 Ehrlichkeit, Genauigkeit, Präzision
35.3 Lehren aus meiner Praxis
35.3.1 Geschichte 1: Vektoren
35.3.2 Geschichte 2: pCCU
35.3.3 Die Lehre
35.4 Genauigkeit und Präzision
35.5 Aggregation
35.6 Ehrlichkeit
35.7 Druck
Kapitel 36:Respekt gegenüber Mitprogrammierern
Kapitel 37: Niemals aufhören zu lernen
Nachwort
Bibliografie
Anhang: Die Clean-Code-Debatte
A.1 Einführung
A.2 Methodenlänge
A.2.1 Zusammenfassung zur Methodenlänge
A.3 Kommentare
A.3.1 Zusammenfassung zu Kommentaren
A.3.2 Johns Neufassung von PrimeGenerator
A.3.3 Eine Geschichte von zwei Programmierern
A.3.4 Bobs Neufassung von PrimeGenerator2
A.4 Test-Driven Development
A.4.1 TDD-Zusammenfassung
A.5 Abschließende Bemerkungen
Stichwortverzeichnis

System requirements

Save as PDF Copy link into clipboard

Schweitzer Fachinformationen

Clean Code

Description

More details

Other editions

Additional editions

Previous edition

Persons

Content

System requirements