Seit der Veröffentlichung eines Java-Magazin Artikels (Dez. 2010) über Clean-Code-Development gehöre ich nun auch zu den „Missionaren“ dieser Bewegung. Das vielzitierte Buch Clean Code von Robert C. Martin ist tatsächlich eine sehr gute Grundlage und wird – so meine Hoffnung – bald ein Klassiker für jeden Software-Entwickler.
Mein Eindruck ist, dass das letzte Jahrzehnt von der Idee geprägt war, Software ähnlich wie in anderen Industrie-Fertigungen in kurzer Zeit und mit begrenztem Budget zu fabrizieren. Zu den positiven Ergebnissen zählen die Erfolge bei den agilen Entwicklungsprozessen und die der Code-Generierung. In allen bis auf ein Projekt habe ich allerdings eine entsprechende Qualitätssicherung (wie bei anderen Industrie-Fertigungen) vermisst.
Ich kann mich gut an einen Vortrag eines Geschäftsführers eines großen Software-Hauses erinnern, der den Software-Entwicklern zu verstehen gab, dass Software wie ein Massenprodukt herzustellen sei und dass ein Entwickler sich von dem Gedanken verabschieden mögen, er vollführe eine künstlerische Tätigkeit. Natürlich hat er Recht: Der überzogene Status als Künstler, der noch aus den 60er Jahren stammt, ist mit Sicherheit überholt. Dennoch zielte sein Vortrag darauf ab, dass auch Software wie am Fließband durch geeignete Prozesse am Ende massenhaft herauspurzeln müsse.
in diesem Fall war es ein großer Management-Fehler. Insbesondere vor dem Hintergrund, dass zu der Zeit ein langlebiges Produkt erstellt wurde und keine „Wegwerf-Applikation für das Weihnachtsgeschäft“. Das Feedback eines Kunden nach der Auslieferung: „So schlecht habe man das Produkt niemals vermutet!“. Insgesamt wurde es weniger als zehnmal verkauft. Das Logfile wimmelte vor Exceptions, sodass nur Experten noch sagen konnten, welche davon gravierend und welche eher „harmloserer Natur“ sind.
Das Problem war irgendwann, dass auch niemand mehr von den Entwicklern das Produkt gut fand. Niemand mehr wollte Verantwortung für die Code-Qualität tragen. Die Verrottung nahm seinen üblichen Lauf.
Wie in den meisten Fällen ist die goldene Mitte wohl wieder der richtige Weg. Auch wenn die Softwareproduktion nicht gerade ein Kunstform ist, so kann sie doch, wie ich finde, zu einem guten, soliden Handwerk werden – für mich das spannendste und interessanteste (das ist natürlich Geschmacksache).
Ich denke, dass die Einstellung zum eigenen Produkt einen recht hohen Einfluss auf die Code-Qualität hat. Ein Entwickler darf und soll sich beim Anblick auf ein gelungenes Design seiner Klassen und der schönen Gestaltung des Source-Codes ebenso erfreuen wie ein Schreiner, Steinmetz, Maler, Architekt, Ingenieur, etc. nach der Fertigstellung seiner Werke. Wenn ich entscheiden könnte, würde ich einem (professionellen) Entwickler stets die Zeit geben, seine Software „clean“ zu machen (außer bei einer „Wegwerf-Applikation fürs Weihnachtsgeschäft“) – und das Gute: Eigentlich hat der Entwickler ja stets diese Möglichkeit. Welche Manager kann denn ernsthaft vorschreiben, dieser oder jener Teil dürfe maximal so und soviel Stunden kosten?
Aus diesem Grund bin ich so erfreut darüber, dass die Clean-Code-Bewegung genau diese Richtung einschlägt – wahrscheinlich als Folge von leidvollen Erfahrungen bzgl. der mangelhaften Produkte des letzten Jahrzehnts, die sich mittlerweile in der Wartung oder Weiterentwicklung befinden und dort nach wie vor immens hohe Aufwände verursachen.