Clean Coder

Erfolgreiche Programmierer haben eines gemeinsam: Die Praxis der Software-Entwicklung ist ihnen eine Herzensangelegenheit. Auch wenn sie unter einem nicht nachlassenden Druck arbeiten, setzen sie sich engagiert ein. Software-Entwicklung ist für sie eine Handwerkskunst. In Clean Coder stellt der legendäre Software-Experte Robert C. Martin die Disziplinen, Techniken, Tools und Methoden vor, die Programmierer zu Profis machen. Dieses Buch steckt voller praktischer Ratschläge und behandelt alle wichtigen Themen vom professionellen Verhalten und Zeitmanagement über die Aufwandsschätzung bis zum Refactoring und Testen. Hier geht es um mehr als nur um Technik: Es geht um die innere Haltung. Martin zeigt, wie Sie sich als Software-Entwickler professionell verhalten, gut und sauber arbeiten und verlässlich kommunizieren und planen. Er beschreibt, wie Sie sich schwierigen Entscheidungen stellen und zeigt, dass das eigene Wissen zu verantwortungsvollem Handeln verpflichtet. Großartige Software ist etwas Bewundernswertes: Sie ist leistungsfähig, elegant, funktional und erfreut bei der Arbeit sowohl den Entwickler als auch den Anwender. Hervorragende Software wird nicht von Maschinen geschrieben, sondern von Profis, die sich dieser Handwerkskunst unerschütterlich verschrieben haben. Clean Coder hilft Ihnen, zu diesem Kreis zu gehören. Robert C. 'Uncle Bob' Martin ist seit 1970 Programmierer und bei Konferenzen in aller Welt ein begehrter Redner. Zu seinen Büchern gehören Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code und Agile Software Development: Principles, Patterns, and Practices. Als überaus produktiver Autor hat 'Uncle Bob' Hunderte von Artikeln, Abhandlungen und Blogbeiträgen verfasst. Er war Chefredakteur bei The C++ Report und der erste Vorsitzende der Agile Alliance. Martin gründete und leitet die Firma Object Mentor, Inc., die sich darauf spezialisiert hat, Unternehmen bei der Vollendung ihrer Projekte behilflich zu sein. In diesem Buch lernen Sie: Was es bedeutet, sich als echter Profi zu verhalten Wie Sie mit Konflikten, knappen Zeitplänen und unvernünftigen Managern umgehen Wie Sie beim Programmieren im Fluss bleiben und Schreibblockaden überwinden Wie Sie mit unerbittlichem Druck umgehen und Burnout vermeiden Wie Sie Ihr Zeitmanagement optimieren Wie Sie für Umgebungen sorgen, in denen Programmierer und Teams wachsen und sich wohlfühlen Wann Sie 'Nein' sagen sollten - und wie Sie das anstellen Wann Sie 'Ja' sagen sollten - und was ein Ja wirklich bedeutet Aus dem Inhalt: Verantwortung übernehmen Feindliche Rollen Ein Teamplayer sein Verbindliche Sprache Der Flow-Zustand Schreibblockaden Test Driven Development Das Coding Dojo Akzeptanztests Teststrategien Zeitmanagement Aufwandsschätzungen Umgang mit Druck Mentoring, Lehrzeiten und die Handwerkskunst Werkzeuge und Hilfsmittel

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;5 3;Impressum;6 4;Inhaltsverzeichnis;9 5;Vorwort;15 6;Einführung;21 7;Danksagungen;25 8;Über den Autor;29 9;Auf dem Titelbild;31 10;Kapitel 1: Professionalität;39 10.1;1.1 Seien Sie vorsichtig, wonach Ihnen verlangt;39 10.2;1.2 Verantwortung übernehmen;40 10.3;1.3 Erstens: Richte keinen Schaden an;42 10.3.1;1.3.1 Beschädige nicht die Funktion;42 10.3.2;1.3.2 Beschädige nicht die Struktur;45 10.4;1.4 Arbeitsethik;47 10.4.1;1.4.1 Sie sollten sich in Ihrem Bereich auskennen;48 10.4.2;1.4.2 Lebenslanges Lernen;49 10.4.3;1.4.3 Praxis;50 10.4.4;1.4.4 Teamwork;51 10.4.5;1.4.5 Mentorenarbeit;51 10.4.6;1.4.6 Sie sollten sich in Ihrem Arbeitsgebiet auskennen;51 10.4.7;1.4.7 Identifizieren Sie sich mit Ihrem Arbeitgeber bzw. Kunden;52 10.4.8;1.4.8 Bescheidenheit;52 10.5;1.5 Bibliografie;52 11;Kapitel 2: Nein sagen;53 11.1;2.1 Feindliche Rollen;55 11.1.1;2.1.1 Was ist mit dem Warum?;58 11.2;2.2 Hoher Einsatz;58 11.3;2.3 Ein Teamplayer sein;60 11.3.1;2.3.1 Versuchen;62 11.3.2;2.3.2 Passive Aggression;64 11.4;2.4 Die Kosten eines Ja;65 11.5;2.5 Code unmöglich;72 12;Kapitel 3: Ja sagen;75 12.1;3.1 Verbindliche Sprache;76 12.1.1;3.1.1 So erkennt man mangelnde Selbstverpflichtung;77 12.1.2;3.1.2 Wie echte Selbstverpflichtung klingt;78 12.1.3;3.1.3 Zusammenfassung;80 12.2;3.2 Lernen, wie man Ja sagt;81 12.2.1;3.2.1 Die Kehrseite von Ich versuchs mal;81 12.2.2;3.2.2 Der Disziplin verpflichtet;82 12.3;3.3 Schlussfolgerung;84 13;Kapitel 4: Programmieren;85 13.1;4.1 Bereit sein;86 13.1.1;4.1.1 Code um drei Uhr früh;87 13.1.2;4.1.2 Sorgencode;88 13.2;4.2 Der Flow-Zustand;89 13.2.1;4.2.1 Musik;90 13.2.2;4.2.2 Unterbrechungen;91 13.3;4.3 Schreibblockaden;92 13.3.1;4.3.1 Kreativer Input;92 13.4;4.4 Debugging;93 13.4.1;4.4.1 Zeit zum Debuggen;96 13.5;4.5 Die eigene Energie einteilen;96 13.5.1;4.5.1 Wann man den Stift weglegen muss;97 13.5.2;4.5.2 Die Heimfahrt;97 13.5.3;4.5.3 Die Dusche;97 13.6;4.6 In Verzug sein;98 13.6.1;4.6.1 Hoffnung;98 13.6.2;4.6.2 Sich beeilen;98 13.6.
3;4.6.3 Überstunden;99 13.6.4;4.6.4 Unlautere Ablieferung;99 13.6.5;4.6.5 Definieren Sie fertig und erledigt;100 13.7;4.7 Hilfe;100 13.7.1;4.7.1 Anderen helfen;101 13.7.2;4.7.2 Hilfe annehmen;101 13.7.3;4.7.3 Mentorenarbeit;102 13.8;4.8 Bibliografie;102 14;Kapitel 5: Test Driven Development;103 14.1;5.1 The Jury is in;104 14.2;5.2 Die drei Gesetze des TDD;105 14.2.1;5.2.1 Die Litanei der Vorteile;105 14.2.2;5.2.2 Die professionelle Option;108 14.3;5.3 Was TDD nicht ist;109 14.4;5.4 Bibliografie;109 15;Kapitel 6: Praktizieren und Üben;111 15.1;6.1 Etwas Hintergrund übers Üben;111 15.1.1;6.1.1 22 Nullen;112 15.1.2;6.1.2 Durchlaufzeiten;113 15.2;6.2 Das Coding Dojo;114 15.2.1;6.2.1 Kata;115 15.2.2;6.2.2 Waza;116 15.2.3;6.2.3 Randori;117 15.3;6.3 Die eigene Erfahrung ausbauen;117 15.3.1;6.3.1 Open Source;118 15.3.2;6.3.2 Ethisch handeln;118 15.4;6.4 Schlussfolgerung;118 15.5;6.5 Bibliografie;118 16;Kapitel 7: Akzeptanztests;119 16.1;7.1 Anforderungen kommunizieren;119 16.1.1;7.1.1 Verfrühte Präzisierung;121 16.2;7.2 Akzeptanztests;124 16.2.1;7.2.1 Die Definition of Done;124 16.2.2;7.2.2 Kommunikation;127 16.2.3;7.2.3 Automatisierung;127 16.2.4;7.2.4 Zusätzliche Arbeit;128 16.2.5;7.2.5 Wer schreibt die Akzeptanztests und wann?;128 16.2.6;7.2.6 Die Rolle des Entwicklers;129 16.2.7;7.2.7 Verhandlungen über die Tests und passive Aggression;130 16.2.8;7.2.8 Akzeptanz- und Unit-Tests;132 16.2.9;7.2.9 GUIs und andere Komplikationen;132 16.2.10;7.2.10 Andauernde Integration;134 16.3;7.3 Schlussfolgerung;134 17;Kapitel 8: Teststrategien;135 17.1;8.1 Für die Qualitätssicherung sollte nichts übrig bleiben;135 17.1.1;8.1.1 Die Qualitätssicherung gehört zum Team;135 17.2;8.2 Die Pyramide der Testautomatisierung;136 17.2.1;8.2.1 Unit-Tests;136 17.2.2;8.2.2 Komponententests;137 17.2.3;8.2.3 Integrationstests;138 17.2.4;8.2.4 Systemtests;139 17.2.5;8.2.5 Manuelle explorative Tests;139 17.3;8.3 Schlussfolgerung;140 17.4;8.4 Bibliografie;140 18;Kapitel 9: Zeitmanagement;141 18.1;9.1 Meet
ings;142 18.1.1;9.1.1 Absagen;142 18.1.2;9.1.2 Sich ausklinken;143 18.1.3;9.1.3 Tagesordnung und Ziel;143 18.1.4;9.1.4 Stand-up-Meetings;144 18.1.5;9.1.5 Planungstreffen zur Iteration;144 18.1.6;9.1.6 Retrospektive und Demo der Iteration;145 18.1.7;9.1.7 Auseinandersetzungen und Meinungsverschiedenheiten;145 18.2;9.2 Fokus-Manna;146 18.2.1;9.2.1 Schlaf;147 18.2.2;9.2.2 Koffein;147 18.2.3;9.2.3 Die Akkus aufladen;147 18.2.4;9.2.4 Muskelfokus;147 18.2.5;9.2.5 Input vs. Output;148 18.3;9.3 Zeitfenster und Tomaten;148 18.4;9.4 Vermeidung;149 18.4.1;9.4.1 Umkehrung der Prioritäten;149 18.5;9.5 Sackgassen;150 18.6;9.6 Morast, Moore, Sümpfe und andere Schlamassel;150 18.7;9.7 Schlussfolgerung;151 19;Kapitel 10: Aufwandsschätzungen;153 19.1;10.1 Was eine Aufwandsschätzung ist;155 19.1.1;10.1.1 Ein Commitment;155 19.1.2;10.1.2 Eine Aufwandsschätzung;155 19.1.3;10.1.3 Implizierte Commitments;157 19.2;10.2 PERT;158 19.3;10.3 Aufgaben schätzen;161 19.3.1;10.3.1 Wideband Delphi;161 19.4;10.4 Das Gesetz der großen Zahlen;163 19.5;10.5 Schlussfolgerung;164 19.6;10.6 Bibliografie;164 20;Kapitel 11: Äußerer Druck;165 20.1;11.1 Druck vermeiden;167 20.1.1;11.1.1 Commitments;167 20.1.2;11.1.2 Sauber arbeiten;167 20.1.3;11.1.3 Verhalten in der Krise;168 20.2;11.2 Umgang mit Druck;168 20.2.1;11.2.1 Keine Panik;168 20.2.2;11.2.2 Kommunizieren Sie;169 20.2.3;11.2.3 Verlassen Sie sich auf Ihre Disziplinen;169 20.2.4;11.2.4 Hilfe holen;169 20.3;11.3 Schlussfolgerung;170 21;Kapitel 12: Teamwork;171 21.1;12.1 Programmierer kontra Menschen;172 21.1.1;12.1.1 Programmierer kontra Arbeitgeber;173 21.1.2;12.1.2 Programmierer kontra Programmierer;175 21.2;12.2 Kleinhirne;177 21.3;12.3 Schlussfolgerung;178 22;Kapitel 13: Teams und Projekte;179 22.1;13.1 Harmoniert es?;179 22.1.1;13.1.1 Das zusammengeschweißte Team;179 22.1.2;13.1.2 Aber wie managt man so etwas?;181 22.1.3;13.1.3 Das Dilemma des Product Owner;181 22.2;13.2 Schlussfolgerung;182 22.3;13.3 Bibliografie;182 23;Kapitel 14: Mentoring, Lehrz
eiten und die Handwerkskunst;183 23.1;14.1 Der Grad des Versagens;183 23.2;14.2 Mentoring;184 23.2.1;14.2.1 Digi-Comp I Mein erster Computer;184 23.2.2;14.2.2 Die ECP-18 in der Highschool;185 23.2.3;14.2.3 Unkonventionelles Mentoring;188 23.2.4;14.2.4 Schicksalsschläge;189 23.3;14.3 Die Lehrzeit;189 23.3.1;14.3.1 Die Lehrzeit bei der Software;191 23.3.2;14.3.2 Die Realität;192 23.4;14.4 Die Handwerkskunst;193 23.4.1;14.4.1 Menschen überzeugen;193 23.5;14.5 Schlussfolgerung;193 24;Anhang A: Werkzeuge und Hilfsmittel;195 24.1;A.1 Tools;196 24.2;A.2 Quellcodekontrolle;197 24.2.1;A.2.1 Ein Enterprise-System der Quellcodekontrolle;197 24.2.2;A.2.2 Pessimistisches kontra optimistisches Locking;197 24.2.3;A.2.3 CVS/SVN;198 24.2.4;A.2.4 git;198 24.3;A.3 IDE/Editor;201 24.3.1;A.3.1 vi;201 24.3.2;A.3.2 Emacs;201 24.3.3;A.3.3 Eclipse/IntelliJ;201 24.3.4;A.3.4 TextMate;202 24.4;A.4 Issue-Tracking-Systeme;202 24.4.1;A.4.1 Bug-Zähler;203 24.5;A.5 Continuous Build;203 24.6;A.6 Tools für Unit-Tests;204 24.7;A.7 Tools für Komponententests;205 24.7.1;A.7.1 Die Definition of Done;205 24.7.2;A.7.2 FitNesse;205 24.7.3;A.7.3 Andere Tools;206 24.8;A.8 Tools für Integrationstests;206 24.9;A.9 UML/MDA;207 24.9.1;A.9.1 Die Details;207 24.9.2;A.9.2 Keine Hoffnung, keine Änderung;209 24.10;A.10 Schlussfolgerung;209 25;Stichwortverzeichnis;210