Clean Coder (eBook)
216 Seiten
MITP Verlags GmbH & Co. KG
978-3-8266-3207-5 (ISBN)
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.
Cover 1
Titel 5
Impressum 6
Inhaltsverzeichnis 9
Vorwort 15
Einführung 21
Danksagungen 25
Über den Autor 29
Auf dem Titelbild 31
Kapitel 1: Professionalität 39
1.1 Seien Sie vorsichtig, wonach Ihnen verlangt 39
1.2 Verantwortung übernehmen 40
1.3 Erstens: Richte keinen Schaden an 42
1.3.1 Beschädige nicht die Funktion 42
1.3.2 Beschädige nicht die Struktur 45
1.4 Arbeitsethik 47
1.4.1 Sie sollten sich in Ihrem Bereich auskennen 48
1.4.2 Lebenslanges Lernen 49
1.4.3 Praxis 50
1.4.4 Teamwork 51
1.4.5 Mentorenarbeit 51
1.4.6 Sie sollten sich in Ihrem Arbeitsgebiet auskennen 51
1.4.7 Identifizieren Sie sich mit Ihrem Arbeitgeber bzw. Kunden 52
1.4.8 Bescheidenheit 52
1.5 Bibliografie 52
Kapitel 2: Nein sagen 53
2.1 Feindliche Rollen 55
2.1.1 Was ist mit dem Warum? 58
2.2 Hoher Einsatz 58
2.3 Ein »Teamplayer« sein 60
2.3.1 Versuchen 62
2.3.2 Passive Aggression 64
2.4 Die Kosten eines Ja 65
2.5 Code unmöglich 72
Kapitel 3: Ja sagen 75
3.1 Verbindliche Sprache 76
3.1.1 So erkennt man mangelnde Selbstverpflichtung 77
3.1.2 Wie echte Selbstverpflichtung klingt 78
3.1.3 Zusammenfassung 80
3.2 Lernen, wie man »Ja« sagt 81
3.2.1 Die Kehrseite von »Ich versuch’s mal« 81
3.2.2 Der Disziplin verpflichtet 82
3.3 Schlussfolgerung 84
Kapitel 4: Programmieren 85
4.1 Bereit sein 86
4.1.1 Code um drei Uhr früh 87
4.1.2 Sorgencode 88
4.2 Der Flow-Zustand 89
4.2.1 Musik 90
4.2.2 Unterbrechungen 91
4.3 Schreibblockaden 92
4.3.1 Kreativer Input 92
4.4 Debugging 93
4.4.1 Zeit zum Debuggen 96
4.5 Die eigene Energie einteilen 96
4.5.1 Wann man den Stift weglegen muss 97
4.5.2 Die Heimfahrt 97
4.5.3 Die Dusche 97
4.6 In Verzug sein 98
4.6.1 Hoffnung 98
4.6.2 Sich beeilen 98
4.6.3 Überstunden 99
4.6.4 Unlautere Ablieferung 99
4.6.5 Definieren Sie »fertig und erledigt« 100
4.7 Hilfe 100
4.7.1 Anderen helfen 101
4.7.2 Hilfe annehmen 101
4.7.3 Mentorenarbeit 102
4.8 Bibliografie 102
Kapitel 5: Test Driven Development 103
5.1 The Jury is in 104
5.2 Die drei Gesetze des TDD 105
5.2.1 Die Litanei der Vorteile 105
5.2.2 Die professionelle Option 108
5.3 Was TDD nicht ist 109
5.4 Bibliografie 109
Kapitel 6: Praktizieren und Üben 111
6.1 Etwas Hintergrund übers Üben 111
6.1.1 22 Nullen 112
6.1.2 Durchlaufzeiten 113
6.2 Das Coding Dojo 114
6.2.1 Kata 115
6.2.2 Waza 116
6.2.3 Randori 117
6.3 Die eigene Erfahrung ausbauen 117
6.3.1 Open Source 118
6.3.2 Ethisch handeln 118
6.4 Schlussfolgerung 118
6.5 Bibliografie 118
Kapitel 7: Akzeptanztests 119
7.1 Anforderungen kommunizieren 119
7.1.1 Verfrühte Präzisierung 121
7.2 Akzeptanztests 124
7.2.1 Die »Definition of Done« 124
7.2.2 Kommunikation 127
7.2.3 Automatisierung 127
7.2.4 Zusätzliche Arbeit 128
7.2.5 Wer schreibt die Akzeptanztests und wann? 128
7.2.6 Die Rolle des Entwicklers 129
7.2.7 Verhandlungen über die Tests und passive Aggression 130
7.2.8 Akzeptanz- und Unit-Tests 132
7.2.9 GUIs und andere Komplikationen 132
7.2.10 Andauernde Integration 134
7.3 Schlussfolgerung 134
Kapitel 8: Teststrategien 135
8.1 Für die Qualitätssicherung sollte nichts übrig bleiben 135
8.1.1 Die Qualitätssicherung gehört zum Team 135
8.2 Die Pyramide der Testautomatisierung 136
8.2.1 Unit-Tests 136
8.2.2 Komponententests 137
8.2.3 Integrationstests 138
8.2.4 Systemtests 139
8.2.5 Manuelle explorative Tests 139
8.3 Schlussfolgerung 140
8.4 Bibliografie 140
Kapitel 9: Zeitmanagement 141
9.1 Meetings 142
9.1.1 Absagen 142
9.1.2 Sich ausklinken 143
9.1.3 Tagesordnung und Ziel 143
9.1.4 Stand-up-Meetings 144
9.1.5 Planungstreffen zur Iteration 144
9.1.6 Retrospektive und Demo der Iteration 145
9.1.7 Auseinandersetzungen und Meinungsverschiedenheiten 145
9.2 Fokus-Manna 146
9.2.1 Schlaf 147
9.2.2 Koffein 147
9.2.3 Die Akkus aufladen 147
9.2.4 Muskelfokus 147
9.2.5 Input vs. Output 148
9.3 Zeitfenster und Tomaten 148
9.4 Vermeidung 149
9.4.1 Umkehrung der Prioritäten 149
9.5 Sackgassen 150
9.6 Morast, Moore, Sümpfe und andere Schlamassel 150
9.7 Schlussfolgerung 151
Kapitel 10: Aufwandsschätzungen 153
10.1 Was eine Aufwandsschätzung ist 155
10.1.1 Ein Commitment 155
10.1.2 Eine Aufwandsschätzung 155
10.1.3 Implizierte Commitments 157
10.2 PERT 158
10.3 Aufgaben schätzen 161
10.3.1 Wideband Delphi 161
10.4 Das Gesetz der großen Zahlen 163
10.5 Schlussfolgerung 164
10.6 Bibliografie 164
Kapitel 11: Äußerer Druck 165
11.1 Druck vermeiden 167
11.1.1 Commitments 167
11.1.2 Sauber arbeiten 167
11.1.3 Verhalten in der Krise 168
11.2 Umgang mit Druck 168
11.2.1 Keine Panik 168
11.2.2 Kommunizieren Sie 169
11.2.3 Verlassen Sie sich auf Ihre Disziplinen 169
11.2.4 Hilfe holen 169
11.3 Schlussfolgerung 170
Kapitel 12: Teamwork 171
12.1 Programmierer kontra Menschen 172
12.1.1 Programmierer kontra Arbeitgeber 173
12.1.2 Programmierer kontra Programmierer 175
12.2 Kleinhirne 177
12.3 Schlussfolgerung 178
Kapitel 13: Teams und Projekte 179
13.1 Harmoniert es? 179
13.1.1 Das zusammengeschweißte Team 179
13.1.2 Aber wie managt man so etwas? 181
13.1.3 Das Dilemma des Product Owner 181
13.2 Schlussfolgerung 182
13.3 Bibliografie 182
Kapitel 14: Mentoring, Lehrzeiten und die Handwerkskunst 183
14.1 Der Grad des Versagens 183
14.2 Mentoring 184
14.2.1 Digi-Comp I – Mein erster Computer 184
14.2.2 Die ECP-18 in der Highschool 185
14.2.3 Unkonventionelles Mentoring 188
14.2.4 Schicksalsschläge 189
14.3 Die Lehrzeit 189
14.3.1 Die Lehrzeit bei der Software 191
14.3.2 Die Realität 192
14.4 Die Handwerkskunst 193
14.4.1 Menschen überzeugen 193
14.5 Schlussfolgerung 193
Anhang A: Werkzeuge und Hilfsmittel 195
A.1 Tools 196
A.2 Quellcodekontrolle 197
A.2.1 Ein »Enterprise«-System der Quellcodekontrolle 197
A.2.2 Pessimistisches kontra optimistisches Locking 197
A.2.3 CVS/SVN 198
A.2.4 git 198
A.3 IDE/Editor 201
A.3.1 vi 201
A.3.2 Emacs 201
A.3.3 Eclipse/IntelliJ 201
A.3.4 TextMate 202
A.4 Issue-Tracking-Systeme 202
A.4.1 Bug-Zähler 203
A.5 Continuous Build 203
A.6 Tools für Unit-Tests 204
A.7 Tools für Komponententests 205
A.7.1 Die »Definition of Done« 205
A.7.2 FitNesse 205
A.7.3 Andere Tools 206
A.8 Tools für Integrationstests 206
A.9 UML/MDA 207
A.9.1 Die Details 207
A.9.2 Keine Hoffnung, keine Änderung 209
A.10 Schlussfolgerung 209
Stichwortverzeichnis 210
Vorwort
Sie haben sich für dieses Buch entschieden, also darf ich davon ausgehen, dass Sie ein Software-Profi sind. Das ist gut, das bin ich nämlich auch. Und da ich nun schon Ihre Aufmerksamkeit habe, will ich Ihnen berichten, warum ich mir dieses Buch vorgenommen habe.
Alles begann vor nicht allzu langer Zeit an einem gar nicht so weit entfernten Ort. Vorhang auf, Licht und Kamera an, Ton ab ...
Vor einigen Jahren arbeitete ich bei einer mittelgroßen Firma, die Produkte mit besonders strengen behördlichen Auflagen verkaufte. Das ist Ihnen sicherlich geläufig: Wir saßen in einem Großraumbüro in einem dreistöckigen Gebäude. Geschäftsführer und die höheren Ränge hatten eigene Büros, und es dauerte ungefähr eine Woche, um alle relevanten Personen für ein Meeting in den gleichen Raum zu bekommen.
Wir operierten in einem hart umkämpften Marktsegment, als die Regierung ein neues Produkt freigab.
Plötzlich hatten wir eine völlig neue Zielgruppe potenzieller Kunden. Wir brauchten nur dafür zu sorgen, dass sie unser Produkt kauften. Das hieß, wir mussten unsere Unterlagen bis zu einem bestimmten Datum bei der Behörde einreichen, zu einem anderen Termin ein Assessment Audit bestehen und zu einem dritten Termin auf den Markt gehen.
Immer wieder betonte unser Management nachdrücklich, wie wichtig diese Termine seien. Ein kleiner Fehler, und die Regierung würde uns für ein ganzes Jahr vom Markt sperren, und wenn die Kunden sich nicht gleich vom ersten Tag an bei uns anmelden konnten, dann würden sie sich bei anderen Anbietern registrieren, und wir wären aus dem Rennen.
Es war die Art von Umgebung, über die sich manche Leute beschweren und andere betonen, dass hier »der Druck herrscht, der aus Kohle Diamanten formt«.
Ich war der technische Projektmanager, aus der Entwicklungsabteilung heraus dazu ernannt. Meine Verantwortung bestand darin, die Website an besagtem Tag online zu bringen, damit sich die potenziellen Kunden Informationen und vor allem Registrierungsformulare herunterladen konnten. Mein Partner bei diesem Vorhaben war der fürs Business zuständige Projektmanager, den ich hier mal Joe nennen möchte. Joes Rolle war, auf der »anderen« Seite zu arbeiten, also mit der Verkaufs- und Marketingabteilung und den nicht-technischen Anforderungen. Er war auch der Typ, von dem der Kommentar über den Druck, »der aus Kohle Diamanten formt«, stammte.
Wenn Sie sich mit der unternehmerischen Welt Amerikas auskennen und darin gearbeitet haben, dann kennen Sie wahrscheinlich all die Schuldzuweisungen, die anderen die Verantwortung zuschieben, und den Widerwillen gegen Arbeit – alles völlig normal. Unsere Firma hatte für das Problem mit Joe und mir eine interessante Lösung parat.
Es war ein bisschen wie mit Batman und Robin, wie wir unsere Sachen erledigen sollten. In einer bestimmten Büroecke traf ich mich täglich mit dem technischen Team. Wir erstellten jeden Tag den Fahrplan neu, erarbeiteten den kritischen Pfad und räumten anschließend jedes mögliche Hindernis auf diesem kritischen Pfad weg. Wenn jemand bestimmte Software brauchte, besorgten wir sie. Wenn jemand »liebend gerne« die Firewall konfigurieren wollte, aber »ach du meine Güte, es ist ja schon wieder Zeit für die Mittagspause«, dann ließen wir ihm sein Mittagessen anliefern. Wenn jemand an unserem Configuration Ticket arbeiten wollte, aber andere Prioritäten aufgetragen bekommen hatte, dann wandten wir uns an seinen Vorgesetzten.
Dann den Manager.
Dann den Geschäftsführer.
Wir sorgten dafür, dass alles fluppte.
Es wäre etwas übertrieben zu sagen, dass wir Stühle umwarfen, brüllten und tobten, aber wir setzten aus unserer Werkzeugkiste jedes einzelne Instrument ein, um alles auf die Reihe zu bekommen. Wir erfanden nebenher ein paar neue Instrumente und Techniken und machten das auf eine ethische Weise, auf die ich noch heute stolz bin.
Ich betrachtete mich selbst als Teammitglied, das sich keinen Zacken aus der Krone bricht, im Notfall auf die Schnelle auch mal eine SQL-Anweisung zu schreiben oder mit Kollegen zu zweit zu programmieren, damit der Code ablieferbar wird. Zu jener Zeit dachte ich über Joe auch auf diese Weise: Ich betrachtete ihn als Mitglied des Teams und nicht drüberstehend.
Schließlich musste ich erkennen, dass Joe diese Meinung nicht teilte. Das war für mich ein sehr trauriger Tag.
Es war Freitag, ein Uhr nachts. Die Website sollte planmäßig sehr früh am folgenden Montag live gehen.
Wir waren fertig. *FERTIG*. Alle Systeme schnurrten wie Kätzchen, wir waren bereit. Ich ließ das gesamte Tech-Team für das finale Scrum-Meeting zusammenkommen, und nun musste nur noch der sprichwörtliche Schalter umgelegt werden. Mehr als einfach bloß das technische Team hatten wir außerdem auch die Leute aus der Marketing-Abteilung, also die Product Owner, bei uns.
Wir waren stolz. Es war ein toller Moment.
Dann kam Joe vorbei.
Er sagte etwas wie: »Schlechte Nachrichten. Die Rechtsabteilung hat die Registrierungsformulare noch nicht fertig. Also können wir noch nicht live gehen.«
Das war kein sonderlich großes Problem. Die ganze Projektlaufzeit schon waren wir immer wieder mal von der einen oder anderen Sache aufgehalten worden und zogen die Batman-und-Robin-Masche aus dem Effeff durch. Ich war bereit, und meine Antwort lautete im Wesentlichen: »Okay, Partner, machen wir uns noch mal an die Arbeit. Die Rechtsabteilung ist im zweiten Stock, nicht wahr?«
Dann wurde die Geschichte merkwürdig.
Anstatt mir zuzustimmen, fragte Joe: »Wovon redest du da, Matt?«
Ich entgegnete: »Ach, du weißt schon. Unser üblicher Auftritt. Wir reden hier über vier PDFs, oder? Die sind doch schon fertig, und die Rechtsfritzen müssen sie nur abnicken, oder? Komm, wir hängen ein bisschen an ihren Schreibtischen rum, schauen sie ein wenig böse an, und bringen das Ding hier endlich in trockene Tücher!«
Joe stimmte meiner Einschätzung nicht zu, sondern antwortete: »Wir gehen einfach erst Ende nächster Woche live. Keine große Sache.«
Sie können sich wahrscheinlich ausmalen, wie die restliche Unterhaltung weiterging. Sie verlief etwa wie folgt:
Matt:
»Aber warum denn? Die kriegen das doch in ein paar Stunden hin.«
Joe:
»Vielleicht dauert das aber auch länger.«
Matt:
»Aber die haben doch noch das ganze Wochenende! Das ist doch eine Menge Zeit. Komm, wir ziehen das durch!«
Joe:
»Matt, das sind Profis. Wir können sie nicht einfach mit bösen Blicken dazu zwingen, dass sie ihr Privatleben für unser kleines Projekt opfern.«
Matt:
(holt Luft) »Joe ..., was haben wir denn deiner Meinung nach in den vergangenen vier Monaten mit dem Entwicklerteam gemacht?«
Joe:
»Sicher, aber die sind eben Profis.«
Pause.
Tief Luft holen.
Was. Hat. Joe. Gerade. Gesagt?
Zu jener Zeit war ich der Ansicht, dass das technische Team aus Profis besteht, und zwar im besten Sinne des Wortes.
Wenn ich es mir im Nachhinein noch einmal überlege, bin ich mir da nicht mehr so sicher.
Schauen wir uns diese Batman-und-Robin-Masche noch einmal an, und zwar aus einer anderen Perspektive. Ich dachte, dass ich das Team durch Ermahnungen zu Höchstleistungen anspornte, aber ich hege den Verdacht, dass Joe ein Spiel spielte mit der impliziten Annahme, das technische Personal stelle seinen Gegner dar. Denken Sie mal drüber nach: Warum war es nötig, herumzurennen, gegen Stühle zu treten und Kollegen zu bearbeiten?
Hätten wir nicht eher das Team fragen sollen, wann es fertig ist, um eine zuverlässige Aussage zu bekommen? Dieser Antwort hätten wir dann Glauben geschenkt und uns bei diesem Glauben nicht die Finger verbrannt.
Sicher sollten wir als Profis das so machen ... und gleichzeitig auch wiederum nicht. Joe vertraute unseren Antworten nicht und fühlte sich beim Mikromanagement des Teams unwohl. Gleichzeitig vertraute er dem Team der Rechtsabteilung und war nicht gewillt, das Mikromanagement auf sie auszudehnen.
Worum geht es hier eigentlich?
Auf irgendeine Weise hat das Team der Rechtsabteilung einen Professionalismus auf eine Weise demonstriert, wie es das technische Team nicht vermocht hatte.
Irgendwie hatte eine andere Gruppe es geschafft, Joe davon zu überzeugen, dass sie keinen Babysitter brauchte, dass sie keine Spielchen spielte und erwartete, dass sie auf Augenhöhe zu behandeln sei und als Gleichberechtigte respektiert werden wollten.
Nein, ich glaube nicht, dass das etwas mit ein paar schicken Zertifikaten an der Wand zu tun hat oder ein paar Extraseminaren am College, obwohl diese zusätzlichen Jahre am College einem vielleicht implizit ein soziales Training ermöglicht, wie man sich zu verhalten hat.
Seit jenem Tag vor vielen Jahren habe ich mich gefragt, wie der technische Berufsstand sich ändern müsste, damit er als Profis betrachtet wird.
Oh, ich habe so meine paar Ideen. Ich habe ein bisschen gebloggt, viel gelesen, es geschafft, meine eigene Arbeits- und Lebenssituation zu verbessern, und ein paar anderen geholfen. Und doch kannte ich kein Buch, in dem man einen ganzen Plan vorgestellt bekommt und das einem die ganze Sache explizit erläutert.
Dann bekam ich eines Tages aus heiterem Himmel die Anfrage, den frühen Entwurf eines Buches zu prüfen – und zwar genau jenes, das...
Erscheint lt. Verlag | 24.3.2014 |
---|---|
Reihe/Serie | mitp Professional |
Sprache | deutsch |
Themenwelt | Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge |
Schlagworte | Aufwandsschätzung • CVS • Debugging • Entwicklung • Integrationstests • Open Source • Programmieren • Programmiersprache C++ • Programmierung • Qualitätssicherung • Refactoring • Software • Software-Entwicklung • Sprache • Suche • Systemtest • Test • unified modeling language (UML) |
ISBN-10 | 3-8266-3207-9 / 3826632079 |
ISBN-13 | 978-3-8266-3207-5 / 9783826632075 |
Haben Sie eine Frage zum Produkt? |
![PDF](/img/icon_pdf_big.jpg)
Größe: 2,9 MB
Digital Rights Management: ohne DRM
Dieses eBook enthält kein DRM oder Kopierschutz. Eine Weitergabe an Dritte ist jedoch rechtlich nicht zulässig, weil Sie beim Kauf nur die Rechte an der persönlichen Nutzung erwerben.
Dateiformat: PDF (Portable Document Format)
Mit einem festen Seitenlayout eignet sich die PDF besonders für Fachbücher mit Spalten, Tabellen und Abbildungen. Eine PDF kann auf fast allen Geräten angezeigt werden, ist aber für kleine Displays (Smartphone, eReader) nur eingeschränkt geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür einen PDF-Viewer - z.B. den Adobe Reader oder Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür einen PDF-Viewer - z.B. die kostenlose Adobe Digital Editions-App.
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
![EPUB](/img/icon_epub_big.jpg)
Größe: 2,5 MB
Digital Rights Management: ohne DRM
Dieses eBook enthält kein DRM oder Kopierschutz. Eine Weitergabe an Dritte ist jedoch rechtlich nicht zulässig, weil Sie beim Kauf nur die Rechte an der persönlichen Nutzung erwerben.
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich