Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code

h2>Kommentare, Formatierung, StrukturierungFehler-Handling und Unit-TestsZahlreiche Fallstudien, Best Practices, Heuristiken und Code Smells Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen CodeAus dem Inhalt:Lernen Sie, guten Code von schlechtem zu unterscheidenSauberen Code schreiben und schlechten Code in guten umwandelnAussagekräftige Namen sowie gute Funktionen, Objekte und Klassen erstellenCode so formatieren, strukturieren und kommentieren, dass er bestmöglich lesbar istEin vollständiges Fehler-Handling implementieren, ohne die Logik des Codes zu verschleiernUnit-Tests schreiben und Ihren Code testgesteuert entwickeln Selbst schlechter Code kann funktionieren. Aber wenn der Code nicht sauber ist, kann er ein Entwicklungsunternehmen in die Knie zwingen. Jedes Jahr gehen unzählige Stunden und beträchtliche Ressourcen verloren, weil Code schlecht geschrieben ist. Aber das muss nicht sein. Mit Clean Code präsentiert Ihnen der bekannte Software-Experte Robert C. Martin ein revolutionäres Paradigma, mit dem er Ihnen aufzeigt, wie Sie guten Code schreiben und schlechten Code überarbeiten. Zusammen mit seinen Kollegen von Object Mentor destilliert er die besten Praktiken der agilen Entwicklung von sauberem Code zu einem einzigartigen Buch. So können Sie sich die Erfahrungswerte der Meister der Software-Entwicklung aneignen, die aus Ihnen einen besseren Programmierer machen werden - anhand konkreter Fallstudien, die im Buch detailliert durchgearbeitet werden. Sie werden in diesem Buch sehr viel Code lesen. Und Sie werden aufgefordert, darüber nachzudenken, was an diesem Code richtig und falsch ist. Noch wichtiger: Sie werden herausgefordert, Ihre professionellen Werte und Ihre Einstellung zu Ihrem Beruf zu überprüfen. Clean Code besteht aus drei Teilen:Der erste Teil beschreibt die Prinzipien, Patterns und Techniken, die zum Schreiben von sauberem Code benötigt werden. Der zweite Teil besteht aus mehreren, zunehmend komplexeren Fallstudien. An jeder Fallstudie wird aufgezeigt, wie Code gesäubert wird - wie eine mit Problemen behaftete Code-Basis in eine solide und effiziente Form umgewandelt wird. Der dritte Teil enthält den Ertrag und den Lohn der praktischen Arbeit: ein umfangreiches Kapitel mit Best Practices, Heuristiken und Code Smells, die bei der Erstellung der Fallstudien zusammengetragen wurden. Das Ergebnis ist eine Wissensbasis, die beschreibt, wie wir denken, wenn wir Code schreiben, lesen und säubern. Dieses Buch ist ein Muss für alle Entwickler, Software-Ingenieure, Projektmanager, Team-Leiter oder Systemanalytiker, die daran interessiert sind, besseren Code zu produzieren. Über den Autor:Robert C. »Uncle Bob« Martin entwickelt seit 1970 professionell Software. Seit 1990 arbeitet er international als Software-Berater. Er ist Gründer und Vorsitzender von Object Mentor, Inc. , einem Team erfahrener Berater, die Kunden auf der ganzen Welt bei der Programmierung in und mit C++, Java, C#, Ruby, OO, Design Patterns, UML sowie Agilen Methoden und eXtreme Programming helfen.

Robert C. »Uncle Bob« Martin entwickelt seit 1970 professionell Software. Seit 1990 arbeitet er international als Software-Berater. Er ist Gründer und Vorsitzender von Object Mentor, Inc. , einem Team erfahrener Berater, die Kunden auf der ganzen Welt bei der Programmierung in und mit C++, Java, C#, Ruby, OO, Design Patterns, UML sowie Agilen Methoden und eXtreme Programming helfen.

1;Cover;1 2;Titel;3 3;Impressum;4 4;Inhaltsverzeichnis;5 5;Vorwort;15 6;Einführung;21 7;Kapitel 1: Sauberer Code;25 7.1;1.1 Code, Code und nochmals Code;26 7.2;1.2 Schlechter Code;27 7.3;1.3 Die Lebenszykluskosten eines Chaos;28 7.4;1.4 Denkschulen;40 7.5;1.5 Wir sind Autoren;41 7.6;1.6 Die Pfadfinder-Regel;43 7.7;1.7 Vorläufer und Prinzipien;43 7.8;1.8 Zusammenfassung;43 8;Kapitel 2: Aussagekräftige Namen;45 8.1;2.1 Einführung;45 8.2;2.2 Zweckbeschreibende Namen wählen;45 8.3;2.3 Fehlinformationen vermeiden;47 8.4;2.4 Unterschiede deutlich machen;49 8.5;2.5 Aussprechbare Namen verwenden;50 8.6;2.6 Suchbare Namen verwenden;51 8.7;2.7 Codierungen vermeiden;52 8.8;2.8 Mentale Mappings vermeiden;54 8.9;2.9 Klassennamen;55 8.10;2.10 Methodennamen;55 8.11;2.11 Vermeiden Sie humorige Namen;55 8.12;2.12 Wählen Sie ein Wort pro Konzept;56 8.13;2.13 Keine Wortspiele;56 8.14;2.14 Namen der Lösungsdomäne verwenden;57 8.15;2.15 Namen der Problemdomäne verwenden;57 8.16;2.16 Bedeutungsvollen Kontext hinzufügen;57 8.17;2.17 Keinen überflüssigen Kontext hinzufügen;60 8.18;2.18 Abschließende Worte;60 9;Kapitel 3: Funktionen;61 9.1;3.1 Klein!;64 9.2;3.2 Eine Aufgabe erfüllen;65 9.3;3.3 Eine Abstraktionsebene pro Funktion;67 9.4;3.4 Switch-Anweisungen;68 9.5;3.5 Beschreibende Namen verwenden;70 9.6;3.6 Funktionsargumente;71 9.7;3.7 Nebeneffekte vermeiden;75 9.8;3.8 Anweisung und Abfrage trennen;77 9.9;3.9 Ausnahmen sind besser als Fehler-Codes;77 9.10;3.10 Dont Repeat Yourself;80 9.11;3.11 Strukturierte Programmierung;80 9.12;3.12 Wie schreibt man solche Funktionen?;81 9.13;3.13 Zusammenfassung;81 9.14;3.14 SetupTeardownIncluder;82 10;Kapitel 4: Kommentare;85 10.1;4.1 Kommentare sind kein Ersatz für schlechten Code;86 10.2;4.2 Erklären Sie im und durch den Code;87 10.3;4.3 Gute Kommentare;87 10.4;4.4 Schlechte Kommentare;92 11;Kapitel 5: Formatierung;109 11.1;5.1 Der Zweck der Formatierung;109 11.2;5.2 Vertikale Formatierung;110 11.3;5.3 Horizontale Formatierung;119 11.4;5.4 Team-Reg
eln;125 11.5;5.5 Uncle Bobs Formatierungsregeln;125 12;Kapitel 6: Objekte und Datenstrukturen;129 12.1;6.1 Datenabstraktion;129 12.2;6.2 Daten/Objekt-Anti-Symmetrie;131 12.3;6.3 Das Law of Demeter;133 12.4;6.4 Datentransfer-Objekte;136 12.5;6.5 Zusammenfassung;138 13;Kapitel 7: Fehler-Handling;139 13.1;7.1 Ausnahmen statt Rückgabe-Codes;139 13.2;7.2 Try-Catch-Finally-Anweisungen zuerst schreiben;141 13.3;7.3 Unchecked Exceptions;143 13.4;7.4 Ausnahmen mit Kontext auslösen;144 13.5;7.5 Definieren Sie Exception-Klassen mit Blick auf die Anforderungen des Aufrufers;144 13.6;7.6 Den normalen Ablauf definieren;146 13.7;7.7 Keine Null zurückgeben;147 13.8;7.8 Keine Null übergeben;148 13.9;7.9 Zusammenfassung;150 14;Kapitel 8: Grenzen;151 14.1;8.1 Mit Drittanbieter-Code arbeiten;151 14.2;8.2 Grenzen erforschen und kennen lernen;154 14.3;8.3 log4j kennen lernen;154 14.4;8.4 Lern-Tests sind besser als kostenlos;156 14.5;8.5 Code verwenden, der noch nicht existiert;157 14.6;8.6 Saubere Grenzen;158 15;Kapitel 9: Unit-Tests;159 15.1;9.1 Die drei Gesetze der TDD;160 15.2;9.2 Tests sauber halten;161 15.3;9.3 Saubere Tests;163 15.4;9.4 Ein assert pro Test;168 15.5;9.5 F.I.R.S.T.;171 15.6;9.6 Zusammenfassung;172 16;Kapitel 10: Klassen;173 16.1;10.1 Klassenaufbau;173 16.2;10.2 Klassen sollten klein sein!;174 16.3;10.3 Änderungen einplanen;185 17;Kapitel 11: Systeme;191 17.1;11.1 Wie baut man eine Stadt?;191 17.2;11.2 Konstruktion und Anwendung eines Systems trennen;192 17.3;11.3 Aufwärtsskalierung;196 17.4;11.4 Java-Proxies;200 17.5;11.5 Reine Java-AOP-Frameworks;202 17.6;11.6 AspectJ-Aspekte;205 17.7;11.7 Die Systemarchitektur testen;205 17.8;11.8 Die Entscheidungsfindung optimieren;207 17.9;11.9 Standards weise anwenden, wenn sie nachweisbar einen Mehrwert bieten;207 17.10;11.10 Systeme brauchen domänenspezifische Sprachen;208 17.11;11.11 Zusammenfassung;208 18;Kapitel 12: Emergenz;209 18.1;12.1 Saubere Software durch emergentes Design;209 18.2;12.2 Einfache Design-Regel 1: Alle T
ests bestehen;210 18.3;12.3 Einfache Design-Regeln 2-4: Refactoring;211 18.4;12.4 Keine Duplizierung;211 18.5;12.5 Ausdrucksstärke;214 18.6;12.6 Minimale Klassen und Methoden;215 18.7;12.7 Zusammenfassung;215 19;Kapitel 13: Nebenläufigkeit;217 19.1;13.1 Warum Nebenläufigkeit?;218 19.2;13.2 Herausforderungen;220 19.3;13.3 Prinzipien einer defensiven Nebenläufigkeitsprogrammierung;221 19.4;13.4 Lernen Sie Ihre Library kennen;223 19.5;13.5 Lernen Sie Ihre Ausführungsmodelle kennen;224 19.6;13.6 Achten Sie auf Abhängigkeiten zwischen synchronisierten Methoden;226 19.7;13.7 Halten Sie synchronisierte Abschnitte klein;226 19.8;13.8 Korrekten Shutdown-Code zu schreiben, ist schwer;227 19.9;13.9 Threaded-Code testen;227 19.10;13.10 Zusammenfassung;232 20;Kapitel 14: Schrittweise Verfeinerung;235 20.1;14.1 Args-Implementierung;236 20.2;14.2 Args: der Rohentwurf;243 20.3;14.3 String-Argumente;258 20.4;14.4 Zusammenfassung;300 21;Kapitel 15: JUnit im Detail;301 21.1;15.1 Das JUnit-Framework;301 21.2;15.2 Zusammenfassung;316 22;Kapitel 16: Refactoring von SerialDate;317 22.1;16.1 Zunächst bring es zum Laufen!;318 22.2;16.2 Dann mach es richtig!;320 22.3;16.3 Zusammenfassung;336 23;Kapitel 17: Smells und Heuristiken;337 23.1;17.1 Kommentare;337 23.2;17.2 Umgebung;339 23.3;17.3 Funktionen;340 23.4;17.4 Allgemein;340 23.5;17.5 Java;362 23.6;17.6 Namen;366 23.7;17.7 Tests;370 23.8;17.8 Zusammenfassung;372 24;Anhang A: Nebenläufigkeit II;373 24.1;A.1 Client/Server-Beispiel;373 24.2;A.2 Mögliche Ausführungspfade;377 24.3;A.3 Lernen Sie Ihre Library kennen;383 24.4;A.4 Abhängigkeiten zwischen Methoden können nebenläufigen Code beschädigen;387 24.5;A.5 Den Durchsatz verbessern;391 24.6;A.6 Deadlock;394 24.7;A.7 Multithreaded-Code testen;398 24.8;A.8 Threadbasierten Code mit Tools testen;401 24.9;A.9 Zusammenfassung;402 24.10;A.10 Tutorial: kompletter Beispielcode;402 25;Anhang B: org.jfree.date.SerialDate;407 26;Anhang C: Literaturverweise;463 27;Epilog;465 28;Stichwortverzeichnis;467