Robert C. Martin: Clean Coder

Robert C. Martin: Clean Coder

Robert C. Martin
Übersetzung: Jürgen Dubau
Clean Coder: Verhaltensregeln für professionelle Programmierer

1. Auflage
2014, 213 Seiten, Broschur
mitp-Verlag
ISBN: 978-3-8266-9695-4

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Das Buch Clean Coder von Robert C. Martin hat als Thema den professionellen Softwareentwickler, den „Clean Coder“: was muss ein Entwickler wissen, können und wie muss er sich verhalten, damit er aus Sicht des Autors als Profi gelten kann.


Struktur

Das Thema des Buches Clean Coder von Robert C. Martin, der auch als Uncle Bob bekannt ist, hat als Thema den professionellen Softwareentwickler, den „Clean Coder“: was muss ein Entwickler wissen, können und wie muss er sich verhalten, damit er aus Sicht des Autors als Profi gelten kann.

Das Buch hat keine explizite den einzelnen Kapiteln übergeordnete Struktur, es existiert jedoch eine logische Strukturierung. Das erste Kapitel Professionalität geht auf allgemeine Themen ein, die den Leser durch das gesamte Buch begleiten werden. Die Kapitel zwei und drei (Nein sagen und Ja sagen) diskutieren das Thema klare Kommunikation.

Der dritte und umfangreichste Teil geht auf den Akt des Programmierens (Kapitel vier Programmieren) und den begleitenden Tätigkeiten ein (Test Driven Development, Praktizieren und Üben, Akzeptanztests und Teststrategien). Alternativ könnten die Kapitel zum Thema Testen auch als separate Unterteilung betrachtet werden.

Die Kapitel Zeitmanagement und Aufwandsschätzungen betrachten zeitliche Aspekte, während die verbliebenen Kapitel 11 bis 14 auf soziale Aspekte eingehen: Äußerer Druck, Teamwork, Teams und Projekte, Mentoring, Lehrzeiten und die Handwerkskunst.

Abgeschlossen wird das Buch durch einen Werkzeuge und Hilfsmittel betitelten Anhang, der zum Großteil auf den vom Autor beim Entwickeln von Software verwendeten Technologiestack eingeht.

Inhalt

Professionalität (Kapitel 1)

Um als Profi in Uncle Bobs Augen zu gelten, muss man bereit sein Einiges zu leisten. Das wird schon auf der ersten Seite des ersten Kapitels klar. So muss man in erster Linie bereit sein, die Verantwortung für die geleistete Arbeit, aber auch für die eigene Weiterentwicklung übernehmen (dafür sollte man neben den 40 Arbeitswochenstunden weitere 20 Stunden wöchentlich für das Lernen reservieren). Uncle Bob verlangt Qualität von einem Profi: „Rate ich zu einer hundertprozentigen Testabdeckung? Nein, dazu rate ich nicht. Ich fordere sie!“ (S. 44, kursive Hervorhebung im Original) und ebenfalls bedingungslose Identifikation mit dem eigenen Arbeitgeber oder Kunden: „Die Probleme Ihres Arbeitgebers sind Ihre Probleme.“ (S. 52, ebenfalls kursive Hervorhebung im Original).

Kommunikation (Kapitel 2 und 3)

Ebenso, wie bei allem anderen, gelten für die Kommunikation eines Profis hohe Anforderungen. Martin verlangt von Entwicklern klare, verbindliche Aussagen. „Es gibt kein Versuchen“, macht er auf Seite 62 (kursive Hervorhebung im Original) Meister Yoda aus dem Film Star Wars zitierend klar, entweder man sagt als Entwickler „Ja“ und dann ist man für das Ergebnis verantwortlich, oder man sagt „Nein“. Anhand einiger fiktiver Beispiele und Anekdoten zeigt Uncle Bob, wie er sich die Reaktionen eines Profis in Situationen in denen Druck ausgeübt wird, vorstellt.

Programmieren und Testen (Kapitel 4 bis 8)

Programmieren ist eine mental herausfordernde Tätigkeit. Um diese bestmöglich erledigen zu können, muss der Profi sicherstellen, dass er möglichst in Topform ist. Private Sorgen sollen idealerweise auch privat bleiben (vgl. S. 89). Überstunden sollen jedoch bis auf wenige Ausnahmen nicht stattfinden.

Robert Martin ist als Verfechter des Test-Driven Developments (TDD) bekannt, deswegen ist es auch nicht verwunderlich, dass für ihn TDD zum Instrumentarium eines Profis gehört. TDD müsse auch angesichts kritischer Stimmen nicht verteidigt werden. Dabei vergleicht der Autor TDD mit dem Händewaschen eines Chirurgen, der dieses auch nicht verteidigen müsse, weil es eben funktioniere (vgl. S. 104).

Kapitel 6 widmet sich dem Thema Üben. Jeder Profi solle kontinuierlich üben und seine Fähigkeiten ausbauen. Durchführen von Programmier-Katas oder die Arbeit an Open-Source-Projekten sind laut Uncle Bob gute Möglichkeiten zum Üben.

Um dem Ziel keine Fehler der Qualitätssicherung zu überlassen so nahe wie möglich zu kommen, ist eine gute Teststrategie vonnöten, welche eine sinnvolle Testabdeckung auf den Unit-, Komponenten-, Integrations- und Systemebenen vorschreibt (wir erinnern uns, bei Unit-Tests sind es 100%). Akzeptanztests, denen auch eine Kommunikations- und Dokumentationsfunktion zukommt, sind zusammen mit einigen wenigen explorativen Tests ebenfalls sehr wichtig.

Zeitliche Aspekte (Kapitel 9 und 10)

Die Zeit, die zur Verfügung steht, ist für gewöhnlich kurz, unnötige Meetings sollen vermieden werden und die auf der Arbeit verbrachte Zeit solle fokussiert für die richtige Arbeit (Prioritäten setzen) verwendet werden.

Aufwandsschätzungen sind in Martins Augen „der Keil, der zwischen Business und Entwickler getrieben wurde, und Quelle beinahe des gesamten Misstrauens, das diese Beziehung dominiert“ (S. 153). Zwei Seiten später versteht der Leser, weswegen der Autor so dramatisch über Aufwandsschätzungen denkt: für die geschäftliche Seite sind Aufwandsschätzungen Versprechen, für die Entwicklung eher – nun, ja – Schätzungen („Vermutung oder Mutmaßung“ wie es Uncle Bob ausdrückt).

Martin stellt anschließend die Program Evaluation and Review Technique (kurz PERT) vor, welche auf Grundlage dreier Werte (optimistische, „normale“ und pessimistische Schätzung) einen Erwartungswert berechnet und ebenfalls die von Barry Boehm entwickelte Schätztechnik Wideband Delphi, wovon Planning Poker, eine verbreitete Schätzmethode, die Martin ebenfalls beschreibt, eine Abwandlung darstellt.

Um ein Profi zu sein, muss man in der Lage sein, einerseits gute Aufwandsschätzungen zu liefern, ohne sich zu committen, und wenn man sich committet, dann muss dieses Commitment auch erfüllt werden (S. 164).

Soziale Aspekte (Kapitel 11 bis 14)

Bezüglich der sozialen Aspekte hat Uncle Bob etliche Ratschläge:

  • Druck ist durch Ruhe und Fairness (in einem Wort Professionalität) zu begegnen;
  • Programmieren ist in großen Teilen eine soziale Angelegenheit, die es zu meistern gilt;
  • Projekte sollten um bestehende Teams organisiert werden und nicht umgekehrt.

Im letzten Kapitel Mentoring, Lehrzeiten und die Handwerkskunst beschreibt Robert Martin drei Stadien für „die Lehrzeit“ eines professionellen Entwicklers: Lehrling, Geselle und Meister. Martins Schlussfolgerung ist:

Es wird Zeit, dass wir uns in unserer Software-Branche der Tatsache stellen, dass es unsere Aufgabe ist, die nächste Generation der Software-Entwickler zur Reifung zu führen, und das nicht den Universitäten überlassen können. Es wird Zeit, für Programme zu sorgen, die Lehr- und Praktikumszeiten und langfristige Führung und Orientierung ermöglichen.

S. 193 f.

Diskussion

Robert C. Martin beschreibt in seinem Buch Clean Coder: Verhaltensregeln für professionelle Programmierer was einen Profi ausmacht und was diesen von einem „normalen Programmierer“ unterscheidet. Der Autor spricht in seinem Buch Vieles an, was neben den technischen Aspekten des Entwicklerjobs wichtig ist, neigt aber des Öfteren zu etwas extremen und undifferenzierten Positionen. Aber alles der Reihe nach.

Das Buch beginnt mit einer Reihe Einführungen: so gibt es nach dem Vorwort eine (erste) Einführung, der die Danksagungen folgen. In den vier Seiten langen Danksagungen, erfährt der Leser den Lebenslauf Uncle Bobs, dem sich dann noch eine separate Sektion Über den Autor anschließt. Es folgt eine Beschreibung des Titelbilds (betitelt Auf dem Titelbild) und noch ein weiterer mehrseitiger Abschnitt betitelt Unverzichtbare Einführung. Der einleitende Teil würde von einer besseren Einteilung der sich am Anfang des Buches befindenden Information profitieren.

Die Unverzichtbare Einführung schließt mit dem Satz „[a]lso lesen Sie dieses Buch als Katalog meiner eigenen Fehler, als Protokoll meiner eigenen Vergehen und als Richtlinie für Sie, um zu vermeiden, dass Sie in meine Fußstapfen treten“ (S. 37). Uncle Bob erzählt tatsächlich sehr viel aus seinem Leben (keine Sorge, der generelle Ton des Buches ist nicht ganz so demütig, wie das vorherige Zitat vermuten lassen könnte). Er lässt den Leser auch wissen, dass er innerhalb seiner 42 Jahren Programmiererfahrung (die englische Ausgabe wurde 2011 veröffentlicht) schon alles gesehen habe (S. 33).

Es ist durchaus interessant so vieles aus dem Leben eines prominenten Entwicklers zu lesen, an manchen Stellen fehlt mir jedoch der entscheidende Schritt, der die entsprechende Geschichte über den Wert einer reinen Anekdote gehoben hätte. Zum Beispiel: in seinem letzten Job als Angestellter, mit fast schon zwanzig Jahren Berufserfahrung, war Uncle Bob als 80 Stunden pro Woche arbeitender, ständig Druck auf andere ausübender Entwicklungsmanager tätig (vgl. S. 166). Fast zwanzig Jahre sind eine sehr lange Zeit und bedeuten viel Erfahrung, da ist man auch kein Jungspund mehr, der es einfach nicht besser weiß. Man stellt sich unweigerlich die Frage, weswegen knapp zwanzig Jahre lang das Doppelte von dem, was Uncle Bob heute fordert, akzeptabel war.

Allerdings ist es ja auch nicht ganz richtig, dass Robert Martin heute die strikte Einhaltung der 40-Stunden-Woche einfordert und damit bin ich bei den teils extremeren und/oder undifferenzierten Forderungen an einen Profi. Um sich um das professionelle Weiterkommen und um die Weiterbildung kümmern zu können – wofür der Entwickler, laut Martin, selber verantwortlich ist – soll dieser 20 Stunden wöchentlich für das Lernen investieren. Spätestens nach dem ersten Kind wird es aber mit der 60-Stunden-Woche etwas schwierig. Ebenfalls ist Martins Einsatz für Pair Programming nicht überzeugend („Ich werde Ihnen nur sagen, dass Profis Pairing machen.“ – S. 177, kursive Hervorhebung im Original), es wurde sehr viel guter Code ohne Pair Programming geschrieben und er wird es immer noch. Seine Forderung, private Probleme außerhalb der Arbeitszeit zu lösen, weil man dem Arbeitgeber die vollen 40 Stunden schulde (S. 89), mag zwar sachlich richtig sein, aber als Forderung ist es doch unmenschlich. Weitere Beispiele existieren.

Aber ausschließlich negativ über das Buch zu urteilen wäre falsch, Clean Coder bietet durchaus Interessantes und Nützliches. Der große Verdienst des Buches ist meines Erachtens, dass es den Job eines Entwicklers in seiner gesamten Komplexität zeigt: es geht um technische Angelegenheiten aber viel mehr um soziale Aspekte, um Kommunikation, um Disziplin, Selbstmanagement und um all die kleinen hässlichen oder nicht ganz so angenehmen Dinge des Alltags. Und darin hat Uncle Bob recht, es sind seine technischen Fähigkeiten, aber vielmehr die Art, wie er die nichttechnischen Angelegenheiten meistert, die einen Profi von einem „normalen Programmierer“ unterscheiden.

Für angehende oder noch am Anfang stehende Entwickler ist die Lektüre von Clean Coder durchaus empfehlenswert, da es gut zeigt, was alles neben Technik notwendig ist, um ein Profi zu werden. Allerdings muss das Buch mit der Warnung versehen werden, dass nicht alles, was darin präskriptiv und normativ ausgedrückt ist, auch als bindend oder als die einzige „Wahrheit“ betrachtet werden darf.


Zum Autor

Informationen über Robert C. Martin finden Sie hier.


Folgende Bücher könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Als studierter Psychologe und Software Engineer war er sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Mit der Gründung der Rezensionsplattform nososo hat er sich entschieden eigene Wege zu gehen.

Schreibe einen Kommentar