Was heißt professionell?
Die Antwort auf diese Frage erfährt man, wenn man das Buch durchgelesen hat.
Robert Cecil Martin gibt am Anfang keine 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:
Profis zucken nicht mehr mit 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.
| Buchinformationen |
| Titel: | Clean Coder |
| Autor: | Robert C. Martin |
| Verlag: | mitp-Verlag, 2014 |
| Umfang: | 216 Seiten |
| ISBN: | 978-3-8266-9695-4 |
| Preis: | 34,99 € (Druck), 29,99 € (EPUB/PDF) |
