Skip to content

Buch: Clean Coder

Titel Clean Coder
Autor Robert C. Martin
Sprache Deutsch
Genre Fachbuch
Herausgeber mitp-Verlag, 2014
Seitenanzahl 216 Seiten

Es gibt sehr viele Bücher darüber, wie „ordentlicher“ Code auszusehen hat, wobei das teilweise natürlich auch Geschmackssache ist. Robert C. Martin, der u.a. für sein Buch „Clean Code“ bekannt ist, hat das Konzept auf die Entwickler ausgeweitet und will ein paar Verhaltensregeln für professionelle Programmierer geben.

Hinweis: Mit dem Begriff „Entwickler“ in dem Artikel sind sowohl weibliche als auch männliche Personen gemeint.

Was heißt professionell?

Die Antwort auf diese Frage erfährt man, wenn man das Buch durchgelesen hat. Martin gibt nicht am Anfang eine klare Definition von „Professionalität“, sondern zeigt mehrere verschiedene Verhaltensregeln auf und definiert diese als professionelles Vorgehen.

Worauf baut Martin seine Aussagen? Er selbst schreibt am Anfang des Buches, dass viele Ratschläge auf seiner persönlichen Erfahrung beruhen. Und davon hat er genug, schließlich ist er seit 1970 als Programmierer tätig und hat vermutlich jeden Fehler gemacht, den man in dieser Branche machen kann. Martin sagt aber auch, dass nicht alle Ratschläge auf jeden passen. Einige werden sicherlich nur für Kopfschütteln sorgen, aber im Großen und Ganzen kann jeder etwas aus dem Buch mitnehmen.

Verantwortung: Die Basis der Professionalität

Das Buch beginnt mit einem Unglück. Am 28. Januar 1986 explodierte die Raumfähre Challenger kurz nach dem Start. Sieben Menschen kamen dabei ums Leben. Grund für die Explosion war ein Ausfall der Dichtungsringe zwischen zwei Komponenten, weil es an dem Tag zu kalt war und die Dichtungsringe nicht für solche niedrigen Temperaturen ausgelegt waren. Den Ingenieuren der Raumfähre war das Problem bekannt und sie sprachen auch beim Management vor, um den Start zu verschieben. Das Management setzte sich aber darüber hinweg, was zu der vorhergesagten Katastrophe führte.

Was Martin mit dem Beispiel zeigen will, ist dass man als Konstrukteur von etwas die Verantwortung zu tragen hat. Sei es als Ingenieur oder Software-Entwickler. Die Verantwortung des Challenger-Unglücks lag sicherlich auch beim Management, weil sie nicht auf ihre eigenen „Profis“ hörte. Sie lag aber auch bei den Ingenieuren, die sich überstimmen ließen, obwohl sie diese Katastrophe voraussagen konnten. Was Martin sagen will: Profi zucken nicht mehr den Schultern, wenn sie einen Fehler sehen und keiner auf sie hört, sondern sie setzen alles daran, dass nichts und niemand zu Schaden kommt. (Diese Aussage deckt sich im Übrigen auch mit der Aussage von Martin Fowler auf der OOP 2014, dass Entwickler „not just code monkeys“ sind, auch wenn der Kontext ein anderer ist).

Dementsprechend hat jeder Entwickler „seinen“ Code zu verantworten. Er soll zum einen keinen Schaden am Verhalten zulassen (eine Funktion verhält sich plötzlich anders als zu vor), aber auch keinen Schaden an der Struktur. Vor allem der letzte Punkt ist etwas, der bei langjährigen Projekten früher oder später immer zu einem Problem wird, weil sich die Entwickler nicht daran halten, z.B. durch Refactorings für eine klare Struktur zu sorgen.

Testen, testen, testen

Was einen professioneller Entwickler laut Martin auch auszeichnet, ist, dass er weiß, dass sein Code funktioniert. Und hier bedeutet „wissen“ nicht bloß „glauben“, sondern er muss es beweisen können. Das geht entweder durch sehr intensives Code-Studium oder durch Tests, besser noch automatisierte Tests.

Robert C. Martin nennt hier vor allem den Begriff „Test Driven Development“ (kurz TDD). Darunter versteht man, dass man zuerst den Test schreibt, der scheitert, und danach den Code, der den Test durchlaufen lässt. TDD hat dabei noch andere Vorteile, aber in Bezug auf Professionalität zeigt es, dass der Code funktioniert und genau das tut, was von ihm erwartet.

Neben TDD geht Martin noch auf andere Teststrategien wie Akzeptanztests ein, denen ebenfalls ein eigenes Kapitel gewidmet ist.

Profis sind Teamplayer

Wer heute eine Stellenausschreibung für einen Job als Software-Entwickler anschaut, wird das Wörtchen „Teamarbeit“ so gut wie immer lesen. Nach Martin sind die meisten Entwickler zwar eher Einzelgänger und haben lieber mit abstrakten Problemen als mit Menschen zu tun, aber man kommt normalerweise auch nicht darum herum, mit anderen Leuten zusammenzuarbeiten. Und sei es nur, dass irgendjemand die Anforderung stellt, was man als nächstes entwickeln soll. Hier stellt Martin heraus, dass ein Teamplayer nicht zu allem Ja und Amen sagt, sondern alles daran setzt, dass das Team als Ganzes vorwärts kommt.

Hierzu gehört eine klare Kommunikation mit dem Management und Kollegen. Wer kennt es nicht, dass der Software-Manager oder Product Owner auf einen zukommt und fragt: „Schaffst Du das bis nächste Woche Dienstag?“ und man antwortet: „Ich versuch's.“ In der Regel antwortet man nur so schwammig, weil man sich nicht sicher ist bzw. sich sogar sicher ist, es nicht zu schaffen, aber nicht Nein sagen will. Der Software-Manager oder Product Owner hört aber aus dieser Aussage eher ein „Ja, das ist machbar.“ heraus. Man sollte also grundsätzlich klar ansagen, was möglich ist und was nicht. Und man sollte auch grundsätzlich nichts bloß versuchen. Oder wie Yoda schon sagte: „Tu es oder tu es nicht. Es gibt kein Versuchen.“

Zum Teamwork gehört es aber auch, Hilfe anzubieten, wenn man sieht, dass jemand irgendwo hängt. Ebenso sollte man sich Zeit für Kollegen nehmen, die eine Frage haben. Das muss nicht unbedingt sofort sein, weil man ansonsten ständig in seiner aktuellen Tätigkeit unterbrochen wird, aber fünfzehn Minuten später ist ja auch okay. Auf der anderen Seite sollte man in einem Team auch nicht zögern, um Hilfe zu bitten. Vielen Menschen denken, dass Fragen ein Zeichen von Schwäche ist. Ganz im Gegenteil ist fragen menschlich (um das deutschsprachige Ubuntu-Portal zu zitieren), denn niemand weiß alles. Anstatt einen Woche alleine an einem Problem zu knabbern (und damit den Abgabetermin zu gefährden) ist es sinnvoller, jemanden zu fragen, der die Antwort in zehn Minuten parat hat.

Zeiteinteilung und Stichtage

Zur korrekten Kommunikation mit dem Management zählt laut Martin auch, dass man Aufwände richtig abschätzt. Wie der Ausdruck „Aufwandsabschätzung“ aussagt, handelt es sich dabei um keine definitive Zusage, was allen Beteiligten klar sein sollte. Es kann mal kürzer oder mal länger dauern.

Aus diesem Grund gibt Martin verschiedene Schätztechniken an. So werden zum einen das aus der Agilen Entwicklung bekannte „Planning Poker“ genannt, was auf der Delphi-Methode basiert. Zum anderen wird aber auch PERT erwähnt, was für Program Evaluation and Review Technique steht. Die Besonderheit ist hier, dass man die Schätzung nicht als einfache Zahl angibt, sondern als eine Art Mittel aus Bestfall, Normalfall und schlimmsten Fall. Hiervon berechnet Martin auch noch die Standardabweichung, um so die Abweichung für den Schlechtfall einzukalkulieren.

Damit man seine Aufgaben ordentlich und zeitgemäß erfüllen kann, gehört auch eine Zeiteinteilung. Zeitmanagement ist für einen Entwickler normalerweise sehr wichtig, da er viele Aufgaben „gleichzeitig“ bearbeiten oder zumindest im Kopf halten muss. Darauf wird in einem eigenen Kapitel auch eingegangen, was sich unter anderem dem leidigen Thema der Meetings widmet. Laut Martin ist es okay, ein Meeting frühzeitig zu verlassen (oder erst gar nicht teilzunehmen), wenn man nicht mehr benötigt wird. Vor allem die Aussagen, dass es die Pflicht des Vorgesetzten ist, dem Entwickler Meetings zu ersparen, ist interessant, denn oft sind es genau die Vorgesetzten, die einen zu diesen Meetings „ermuntern wollen“ (um es positiv auszudrücken).

Fazit

Lernt man durch das Buch, ein professioneller Programmierer zu werden? Hier kann man ein ganz deutliches und klares „Vielleicht“ als Antwort geben. Grund für diese ausweichende Antwort ist, dass das Wort Professionalität nicht fest von der Welt definiert ist. Robert C. Martin gibt seine Einschätzung, was er unter Professionalität versteht und wie man diese erreichen kann.

Unter dem Gesichtspunkt kann man zum Buch aber zumindest sagen, dass es wirklich sehr viele hilfreiche Tipps enthält, wie man ein besserer Programmierer werden kann. Angefangen bei der Verantwortung, die man für den Code hat, bis hin zu einer störungsfreien Kommunikation zwischen allen Parteien.

Interessant ist auch, dass Martin das Thema Karriere und Fortbildung in die Hände der Entwickler legt. Sicherlich hat auch eine Firma Interesse daran, seine Entwickler weiter zu auszubilden, um neuen Anforderungen gewachsen zu sein. (Aus einem anderen Buch zwischen zwei Managern: „Was ist denn, wenn wir unsere Leute teuer weiterbilden und sie dann den Job wechseln?“ – „Was ist, wenn wir sie nicht weiterbilden und sie bleiben?“) Aber Martin sieht es als Pflicht eines professionellen Programmierers an, sich auch privat weiterzubilden. Sei es durch kleine Fingerübungen am heimischen PC (am besten in einer Sprache, die man nicht täglich nutzt), bis hin zu Mentorenarbeit oder Hilfe in einem Open-Source-Projekt. (Martin selbst zeigt sich zum Beispiel für das Open-Source-Testing-Framework FitNesse verantwortlich.)

Schön ist die klare Gliederung des Buches, deren Kapitel nicht aufeinander aufbauen. So kann man sehr leicht auch nur ein einzelnes Thema durchlesen oder etwas nachlesen, wenn es einen interessiert. Ebenfalls gut sind die Beispiele im Buch, die sehr oft als Gespräch zwischen zwei oder drei Beteiligten dargestellt werden. Nach einem Gespräch analysiert Martin dann, was und wie es gesagt wurde und wo es ggf. zu Problemen bei der Kommunikation kam. Das ist sehr anschaulich und verständlich, da fast jeder schon ähnliche Gespräche gehabt hat.

Eine Besonderheit, die es abschließend noch hervorzuheben gilt ist, dass Robert C. Martin sich gegen den Flow-Zustand ausspricht. Das ist insoweit besonders, da fast alle Programmierbücher propagieren, dass man genau in diesem Zustand bessere Arbeit leistet. Martin ist ein Gegner dieses Flows und versucht alles, nicht dort hineinzukommen bzw. darin zu bleiben, weil man in dem Zustand zwar produktiver ist, aber auch Teile seines Gehirn für rationales Denken ausschaltet und somit eher Fehler macht.

Alles in allem ist „Clean Coder“ ein sehr schönes Buch, das, wenn es einen vielleicht auch nicht gleich professionell werden lässt, zumindest Tipps und Regeln an die Hand gibt, wie man ein besserer Programmierer werden kann.

Trackbacks

deesaster.org am : Buch: Clean Architecture

Vorschau anzeigen
Titel Clean Architecture Autor Robert C. Martin Sprache Deutsch Genre Sachbuch Verlag mitp Verlag, 2018 Seitenanzahl 375 Nach „Clean Code“ und „Clean Coder“ veröffentlicht Onkel Bob sein neuestes Werk: „Clean Architecture“. Vermutlich ist de

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Formular-Optionen