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

Deutsche Ausgabe

Robert C. Martin (Autor)

eBook Download: PDF | EPUB

2013 | 1. Auflage
480 Seiten
MITP Verlags GmbH & Co. KG
978-3-8266-9639-8 (ISBN)

Infos

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.

Inhalt

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

Textauszug

Vorwort

Bei uns in Dänemark zählt Ga-Jol zu den beliebtesten Süßigkeiten. Sein starker Lakritzduft ist ein perfektes Mittel gegen unser feuchtes und oft kühles Wetter. Der Charme, den Ga-Jol für uns Dänen entfaltet, liegt auch an den weisen oder geistreichen Sprüchen, die auf dem Deckel jeder Packung abgedruckt sind. Ich habe mir heute Morgen eine Doppelpackung dieser Köstlichkeit gekauft und fand darauf das folgende alte dänische Sprichwort:

Ærlighed i små ting er ikke nogen lille ting.

Ehrlichkeit in kleinen Dingen ist kein kleines Ding. Dies war ein gutes Omen. Es passte zu dem, was ich hier sagen wollte. Kleine Dinge spielen eine Rolle. In diesem Buch geht es um bescheidene Belange, deren Wert dennoch beträchtlich ist.

Gott steckt in den Details, sagte der Architekt ?Ludwig Mies van der Rohe. Dieses Zitat erinnert an zeitgenössische Auseinandersetzungen über die Rolle der Architektur bei der Software-Entwicklung und insbesondere in der Agilen Welt. Bob und ich führen gelegentlich heiße Diskussionen über dieses Thema. Und ja, Mies van der Rohe war sehr an der Nützlichkeit und der Zeitlosigkeit der Formen des Bauens interessiert, auf denen großartige Architektur basiert. Andererseits wählte er auch persönlich jeden Türknopf für jedes Haus aus, das er entworfen hatte. Warum? Weil kleine Aufgaben eine Rolle spielen.

Bei unserer laufenden »Debatte« über TDD haben Bob und ich festgestellt, dass wir beide der Auffassung sind, dass die Software-?Architektur eine wichtige Rolle bei der Entwicklung spielt, obwohl wir wahrscheinlich verschiedene Vorstellungen davon haben, was genau das bedeutet. Doch solche Differenzen sind relativ unwichtig, weil wir davon ausgehen können, dass verantwortungsbewusste Profis am Anfang eines Projekts eine gewisse Zeit über seinen Ablauf und seine Planung nachdenken. Die Vorstellungen der späten 1990er-Jahre, dass Design nur durch Tests und den Code vorangetrieben werden könnte, sind längst passé. Doch die Aufmerksamkeit im Detail ist ein noch wesentlicherer Aspekt der Professionalität als Visionen im Großen. Erstens: Es ist die Übung im Kleinen, mit der Profis ihr Können und ihr Selbstvertrauen entwickeln, sich an Größeres heranzuwagen. Zweitens: Die kleinste Nachlässigkeit bei der Konstruktion, die Tür, die nicht richtig schließt, die missratene Kachel auf dem Fußboden oder sogar ein unordentlicher Schreibtisch können den Charme des größeren Ganzen mit einem Schlag ruinieren. Darum geht es bei sauberem Code.

Dennoch bleibt die Architektur nur eine Metapher für die ??Software-Entwicklung und insbesondere die Phase der Software, in der das anfängliche Produkt etwa in derselben Weise entsteht, wie ein Architekt ein neues Gebäude hervorbringt. In der heutigen Zeit von Scrum und Agile geht es hauptsächlich darum, ein Produkt schnell auf den Markt zu bringen. Die Fabrik soll mit höchster Kapazität Software produzieren. Nur: Hier geht es um menschliche Fabriken, denkende und führende Programmierer, die eine Aufgabenliste abarbeiten oder sich bemühen, anhand von Benutzer-Stories ein brauchbares Produkt zu erstellen. Ein solches Denken wird von der Metapher der Fabrik dominiert. Die Produktionsaspekte der Herstellung von Autos in Japan, also einer von Fließbändern dominierten Welt, haben viele Ideen von Scrum inspiriert.

Doch selbst in der Automobilindustrie wird der Hauptteil der Arbeit nicht bei der Produktion, sondern bei der Wartung geleistet – oder bei dem Bemühen, sie zu vermeiden. Bei der Software werden die 80 oder mehr Prozent unserer Tätigkeit anheimelnd als »Wartung« bezeichnet, ein beschönigendes Wort für »Reparatur«. Statt uns also auf typische westliche Weise auf die Produktion guter Software zu konzentrieren, sollten wir anfangen, eher wie ein Hausmeister bei der Gebäudeinstandhaltung oder wie ein Kfz-Mechaniker bei der Reparatur von Autos zu denken. Was haben japanische Managementweisheiten dazu zu sagen?

Etwa 1951 erschien ein Qualitätsansatz namens ?Total Productive Maintenance (?TPM; »Umfassendes Management des Produktionsprozesses«, der Ausdruck wird nicht ins Deutsche übersetzt) in der japanischen Szene. Er konzentrierte sich weniger auf die Produktion, sondern mehr auf die Wartung. Eine der fünf Säulen des TPM ist der Satz der so genannten 5S-Prinzipien. 5S bezieht sich auf einen Satz von Disziplinen oder Tätigkeitsbereichen. Tatsächlich verkörpern diese 5S-Prinzipien die Bedeutung von ?Lean – einem anderen Modewort in westlichen Produktionskreisen, das zunehmend auch in der Software-Entwicklung verwendet wird. Diese Prinzipien sind nicht optional. Wie Uncle Bob auf der Titelseite sagt, erfordert die Software-Praxis eine gewisse Disziplin: Fokus, Aufmerksamkeit und Denken. Es geht nicht immer nur darum, aktiv zu sein und die Fabrikausrüstung mit der optimalen Geschwindigkeit zu betreiben. Die ?5S-Philosophie umfasst die folgenden Konzepte:

• ?Seiri oder Organisation (Eselsbrücke: »sortieren«). Zu wissen, wo sich Dinge befinden, ist erfolgsentscheidend. Dazu zählen zum Beispiel Ansätze wie das Vergeben geeigneter Namen. Wenn Sie meinen, die Benennung Ihrer Bezeichner sei nicht wichtig, sollten Sie auf jeden Fall die folgenden Kapitel lesen.

• ?Seiton oder Ordentlichkeit (Eselsbrücke: »aufräumen«). Ein altes Sprichwort sagt: Ein Platz für alles, und alles an seinem Platz. Ein Code-Abschnitt sollte da stehen, wo Sie ihn zu finden erwarten; und falls er nicht da steht, sollten Sie ein Refactoring von Ihrem Code vornehmen, so dass er danach an der erwarteten Stelle steht.

• ?Seiso oder Sauberkeit (Eselsbrücke: »wienern«). Sorgen Sie dafür, dass der Arbeitsplatz frei von herumhängenden Drähten, Müllspuren, Einzelteilen und Abfall ist. Was sagen die Autoren hier über die Vermüllung Ihres Codes mit Kommentaren und auskommentierten Codezeilen, die den Verlauf der Entwicklung oder Wünsche für die Zukunft wiedergeben? Weg damit.

• ?Seiketsu oder Standardisierung. Die kommt zu einem Konsens darüber, wie der Arbeitsplatz sauber gehalten werden soll. Hat dieses Buch etwas über einen konsistenten Codierstil und gemeinsam in der Gruppe befolgte Praktiken zu sagen? Wo kommen diese Standards her? Lesen Sie weiter.

• ?Shutsuke oder Disziplin (Selbst-disziplin). Dies bedeutet, die Disziplin aufzubringen, den Praktiken zu folgen, seine Arbeit regelmäßig zu überdenken und bereit zu sein, sich zu ändern.

Wenn Sie die Herausforderung – jawohl, die Herausforderung – annehmen, dieses Buch zu lesen und anzuwenden, werden Sie den letzten Punkt verstehen und schätzen lernen. Hier kommen wir schließlich zu den Wurzeln einer verantwortlichen professionellen Einstellung in einem Beruf, der sich um den Lebenszyklus eines Produktes kümmern sollte. So wie Automobile und andere Maschinen unter TPM vorbeugend gewartet werden, sollte eine Wartung im Falle eines Zusammenbruchs – also darauf zu warten, dass die Bugs sich zeigen – die Ausnahme sein. Stattdessen sollten Sie eine Ebene höher ansetzen: Inspizieren Sie die Maschinen jeden Tag und tauschen Sie Verschleißteile aus, bevor sie kaputtgehen, oder lassen Sie den sprichwörtlichen Ölwechsel vornehmen, um die Abnutzung des Motors möglichst zu verringern. Für Ihren Code bedeutet das: Nehmen Sie ein gnadenloses Refactoring vor. Sie können mit der Verbesserung noch eine Ebene höher ansetzen, wie es die TPM-Bewegung innovativ vor über 50 Jahren vorgemacht hat: Bauen Sie Maschinen, die von vornherein wartungsfreundlicher sind. Code lesbar zu machen, ist genauso wichtig, wie ihn ausführbar zu machen. Die ultimative Praxis, die in TPM-Kreisen etwa 1960 eingeführt wurde, besteht darin, die alten Maschinen vorbeugend durch vollkommen neue zu ersetzen. Wie Fred ?Brooks anmahnt, sollten wir wahrscheinlich Hauptteile unserer Software etwa alle sieben Jahre von Grund auf erneuern, um die schleichende Ansammlung von ?Cruft (Jargon: Müll, Staub, Unrat) zu beseitigen. Vielleicht sollten wir die von Brooks genannte Zeitspanne drastisch reduzieren und nicht von Jahren, sondern von Wochen, Tagen oder gar Stunden sprechen. Denn dort finden sich die Details.

??Details haben eine mächtige Wirkungskraft. Dennoch hat dieser Ansatz etwas Bescheidenes und Grundsätzliches, so wie wir es vielleicht stereotyp von einem Ansatz erwarten, der japanische Wurzeln für sich in Anspruch nimmt. Aber dies ist nicht nur eine köstliche Art, das Leben zu sehen. Auch die westliche Volksweisheit enthält zahlreiche ähnliche Sprichwörter. Das Seiton-Zitat von oben floss auch aus der Feder eines Priesters in Ohio, der Ordentlichkeit buchstäblich »als Gegenmittel für jede Art von Bösem« sah. Was ist mit Seiso? Sauberkeit kommt gleich nach Göttlichkeit. So schön ein Haus auch sein mag, ein unordentlicher Tisch raubt ihm seinen ganzen Glanz. Was bedeutet Shutsuke in diesen kleinen Dingen? Wer an wenig glaubt, glaubt an viel. Wie wär’s damit, das Refactoring des Codes rechtzeitig durchzuführen, um seine Position für folgende »große« Entscheidungen zu stärken, als die Aufgabe aufzuschieben? Ein Stich zur rechten Zeit erspart dir neun weitere. Wer früh kommt, mahlt zuerst. Was du heute kannst besorgen, das verschiebe nicht auf morgen. (Dies war die ursprüngliche Bedeutung...

Produkt-Details

• Erscheint lt. Verlag: 17.12.2013
• Reihe/Serie: mitp Professional
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge
• Schlagworte: Buch • Entwurfsmuster • HTML • Java • Logik • mitp • Programmiersprache C++ • Programmiertechnik • Programmierung • Ruby • Software-Entwicklung • Test • unified modeling language (UML) • Unit
• ISBN-10: 3-8266-9639-5 / 3826696395
• ISBN-13: 978-3-8266-9639-8 / 9783826696398