James O. Coplien über Clean Code#

Eines unserer Lieblingsbonbons hier in Dänemark ist Ga-Jol, dessen starker Lakritzduft perfekt zu unserem feuchten und oft kühlen Wetter passt. Ein Teil des Charmes von Ga-Jol für uns Dänen sind die weisen oder witzigen Sprüche, die auf der Klappe jeder Schachtel aufgedruckt sind. Heute Morgen kaufte ich eine Doppelpackung dieser Delikatesse und stellte fest, dass sie mit dieser alten dänischen Säge versehen war:

Ærlighed i små ting er ikke nogen lille ting.
Ehrlichkeit in kleinen Dingen ist keine kleine Sache.

Das war ein gutes Omen, das sich mit dem deckt, was ich hier schon sagen wollte. Kleine Dinge sind wichtig. In diesem Buch geht es um bescheidene Anliegen, deren Wert jedoch alles andere als gering ist.

Gott steckt im Detail, sagte der Architekt Ludwig Mies van der Rohe. Dieses Zitat erinnert an die aktuellen Diskussionen über die Rolle der Architektur in der Softwareentwicklung und insbesondere in der agilen Welt. Bob und ich ertappen uns gelegentlich dabei, wie wir uns leidenschaftlich in diesen Dialog einschalten. Und ja, Mies van der Rohe achtete auf die Nützlichkeit und auf die zeitlosen Formen des Bauens, die der großen Architektur zugrunde liegen. Andererseits hat er aber auch jeden Türknauf für jedes von ihm entworfene Haus persönlich ausgewählt. Und warum? Weil die kleinen Dinge wichtig sind. In unserer laufenden “Debatte” über TDD haben Bob und ich festgestellt, dass wir uns einig sind, dass die Softwarearchitektur einen wichtigen Platz in der Entwicklung einnimmt, auch wenn wir wahrscheinlich unterschiedliche Vorstellungen davon haben, was das genau bedeutet. Solche Spitzfindigkeiten sind jedoch relativ unwichtig, da wir davon ausgehen können, dass verantwortungsbewusste Fachleute zu Beginn eines Projekts einige Zeit für Überlegungen und Planung aufwenden. Die Vorstellungen der späten 1990er Jahre, wonach das Design nur von den Tests und dem Code bestimmt wird, sind längst überholt. Dennoch ist die Aufmerksamkeit für Details eine noch wichtigere Grundlage für Professionalität als jede große Vision. Erstens erlangen Fachleute durch die Praxis im Kleinen die Kompetenz und das Vertrauen für die Praxis im Großen. Zweitens: Das kleinste bisschen schlampige Konstruktion, die Tür, die nicht richtig schließt, oder die leicht schiefe Fliese auf dem Boden oder sogar der unordentliche Schreibtisch machen den Charme des großen Ganzen zunichte. Genau darum geht es bei sauberem Code. Dennoch ist die Architektur nur eine Metapher für die Softwareentwicklung und insbesondere für den Teil der Software, der das ursprüngliche Produkt in demselben Sinne liefert, wie ein Architekt ein makelloses Gebäude liefert. In Zeiten von Scrum und Agile liegt der Schwerpunkt darauf, das Produkt schnell auf den Markt zu bringen. Wir wollen, dass die Fabrik mit Höchstgeschwindigkeit läuft, um Software zu produzieren. Das sind menschliche Fabriken: denkende, fühlende Programmierer, die anhand eines Product Backlogs oder einer User Story arbeiten, um ein Produkt zu erstellen. Die Metapher der Fertigung ist in dieser Denkweise immer präsent. Die Produktionsaspekte der japanischen Automobilproduktion, einer Fließbandwelt, inspirieren Scrum zu einem großen Teil.

Doch selbst in der Autoindustrie liegt der Großteil der Arbeit nicht in der Fertigung, sondern in der Wartung - oder deren Vermeidung. In der Softwarebranche werden 80 % oder mehr unserer Arbeit kurioserweise als “Wartung “ bezeichnet: der Akt der Reparatur. Anstatt den typisch westlichen Fokus auf die Produktion guter Software zu legen, sollten wir eher wie Handwerker in der Baubranche oder Automechaniker im Automobilbereich denken. Was hat das japanische Management dazu zu sagen?

Etwa 1951 kam in Japan ein Qualitätskonzept namens Total Productive Maintenance (TPM) auf den Plan. Sein Schwerpunkt liegt auf der Instandhaltung und nicht auf der Produktion. Eine der wichtigsten Säulen von TPM sind die so genannten 5S-Grundsätze. 5S ist eine Reihe von Disziplinen - und hier verwende ich den Begriff “Disziplin” in lehrreicher Weise. Diese 5S-Prinzipien bilden die Grundlage für Lean - ein weiteres Schlagwort in der westlichen Welt und ein immer bekannteres Schlagwort in Softwarekreisen. Diese Grundsätze sind keine Option. Wie Onkel Bob in seinem Vorwort sagt, erfordert gute Softwarepraxis eine solche Disziplin: Konzentration, Geistesgegenwart und Denken. Es geht nicht immer nur darum, etwas zu tun, sondern die Fabrikanlagen dazu zu bringen, mit optimaler Geschwindigkeit zu produzieren. Die 5S-Philosophie umfasst diese Konzepte:

Seiri, oder Organisation (denken Sie an “sort” im Englischen). Zu wissen, wo sich die Dinge befinden - unter Verwendung von Ansätzen wie der geeigneten Benennung - ist entscheidend. Sie glauben, die Benennung von Bezeichnern sei nicht wichtig? Lesen Sie in den folgenden Kapiteln weiter.
Seiton, oder Aufgeräumtheit (denken Sie an “systematisieren” im Englischen). Es gibt ein altes amerikanisches Sprichwort: Ein Platz für alles, und alles an seinem Platz. Ein Stück Code sollte dort sein, wo man es erwartet - und wenn nicht, sollte man es durch Refactoring dorthin bringen.
Seiso, oder Reinigung (denken Sie an “shine” auf Englisch): Halte den Arbeitsplatz frei von herabhängenden Kabeln, Fett, Abfällen und Abfall. Was sagen die Autoren hier über die Vermüllung Ihres Codes mit Kommentaren und auskommentierten Codezeilen, die Geschichte oder Wünsche für die Zukunft festhalten? Entfernen Sie diese.
Seiketsu, oder Standardisierung: Die Gruppe ist sich einig darüber, wie man den Arbeitsplatz sauber halten kann. Glauben Sie, dass dieses Buch irgendetwas über einen konsistenten Kodierungsstil und eine Reihe von Praktiken innerhalb der Gruppe aussagt? Woher kommen diese Standards? Lesen Sie weiter.
Shutsuke, oder Disziplin (Selbstdisziplin). Das bedeutet, die Disziplin zu haben, die Praktiken zu befolgen und die eigene Arbeit häufig zu reflektieren und bereit zu sein, sich zu ändern.

Wenn Sie sich der Herausforderung stellen - ja, der Herausforderung -, dieses Buch zu lesen und anzuwenden, werden Sie den letzten Punkt verstehen und schätzen lernen. Hier kommen wir endlich zu den Wurzeln einer verantwortungsvollen Professionalität in einem Beruf, der sich mit dem Lebenszyklus eines Produkts befassen sollte. Bei der Instandhaltung von Autos und anderen Maschinen im Rahmen von TPM ist die Wartung im Falle eines Ausfalls - das Warten auf das Auftreten von Fehlern - die Ausnahme. Stattdessen gehen wir eine Stufe höher: Wir inspizieren die Maschinen täglich und reparieren Verschleißteile, bevor sie kaputt gehen, oder machen das Äquivalent des sprichwörtlichen Ölwechsels nach 10.000 Meilen, um Verschleiß vorzubeugen. Beim Code sollten Sie gnadenlos überarbeiten. Sie können sich noch eine Stufe weiter verbessern, wie es die TPM-Bewegung vor über 50 Jahren vorschlug: Bauen Sie Maschinen, die von vornherein wartbarer sind. Die Lesbarkeit Ihres Codes ist ebenso wichtig wie seine Ausführbarkeit. Die ultimative Praxis, die in TPM-Kreisen um 1960 eingeführt wurde, besteht darin, sich auf die Einführung völlig neuer Maschinen oder den Ersatz alter Maschinen zu konzentrieren. Wie Fred Brooks uns ermahnt, sollten wir wahrscheinlich alle sieben Jahre oder so größere Softwareteile von Grund auf neu entwickeln, um schleichenden Ballast zu beseitigen. Vielleicht sollten wir Brooks’ Zeitkonstante auf eine Größenordnung von Wochen, Tagen oder Stunden anstelle von Jahren aktualisieren. Darin liegt das Detail.

Im Detail liegt eine große Kraft, und doch hat dieser Lebensansatz etwas Bescheidenes und Tiefgründiges, wie man es stereotyp von jedem Ansatz erwarten könnte, der sich auf japanische Wurzeln beruft. Aber dies ist nicht nur eine östliche Lebensauffassung; auch die englische und amerikanische Volksweisheit ist voll von solchen Mahnungen. Das obige Seiton-Zitat stammt aus der Feder eines Pfarrers aus Ohio, der Ordentlichkeit buchstäblich “als Heilmittel für jedes Übel” ansah. Wie wäre es mit Seiso? Sauberkeit ist gleichbedeutend mit Göttlichkeit. So schön ein Haus auch sein mag, ein unordentlicher Schreibtisch raubt ihm seinen Glanz. Wie steht es mit Shutsuke in diesen kleinen Dingen? Wer im Kleinen treu ist, ist im Großen treu. Wie wäre es, zum richtigen Zeitpunkt eine Überarbeitung vorzunehmen, um die eigene Position für spätere “große” Entscheidungen zu stärken, anstatt sie aufzuschieben? Ein Stich in der Zeit spart neun. Der frühe Vogel fängt den Wurm. Schieben Sie nicht auf Morgen, was Sie heute tun können. (Das war der ursprüngliche Sinn des Ausdrucks “der letzte verantwortliche Moment” in Lean, bis er in die Hände von Software-Beratern fiel.) Wie wäre es, den Platz kleiner, individueller Anstrengungen in einem großen Ganzen zu kalibrieren? Aus kleinen Eicheln wachsen mächtige Eichen. Oder wie wäre es, einfache Präventionsarbeit in den Alltag zu integrieren? Eine Unze Prävention ist mehr wert als ein Pfund Heilung. Ein Apfel am Tag hält den Arzt fern. Der Clean Code ehrt die tiefen Wurzeln der Weisheit unter unserer allgemeinen Kultur, oder unsere Kultur, wie sie einst war oder sein sollte und sein kann, mit der Aufmerksamkeit für Details. Selbst in der großen Architekturliteratur finden wir Hinweise, die auf diese vermeintlichen Details verweisen. Denken Sie an die Türklinken von Mies van der Rohe. Das ist Seiri. Das ist, auf jeden Variablennamen zu achten. Sie sollten eine Variable mit der gleichen Sorgfalt benennen, mit der Sie ein erstgeborenes Kind benennen.

Wie jeder Hausbesitzer weiß, nehmen die Pflege und die ständige Verfeinerung nie ein Ende. Der Architekt Christopher Alexander - der Vater von Mustern und Mustersprachen - betrachtet jeden Akt der Gestaltung selbst als einen kleinen, lokalen Akt der Reparatur. Und er betrachtet die handwerkliche Ausführung schöner Strukturen als alleinige Aufgabe des Architekten; die größeren Formen können den Mustern und ihrer Anwendung durch die Bewohner überlassen werden. Design ist ein ständiger Prozess, nicht nur, wenn wir ein neues Zimmer in ein Haus einbauen, sondern auch, wenn wir darauf achten, neu zu streichen, abgenutzte Teppiche zu ersetzen oder die Küchenspüle zu erneuern. Die meisten Künste spiegeln analoge Empfindungen wider. Auf der Suche nach anderen, die Gottes Zuhause im Detail sehen, befinden wir uns in der guten Gesellschaft des französischen Schriftstellers Gustav Flaubert aus dem 19. Der französische Dichter Paul Valery rät uns, dass ein Gedicht nie fertig ist und immer wieder überarbeitet werden muss, und wenn man aufhört, daran zu arbeiten, ist man ein Verlierer. Diese Beschäftigung mit dem Detail ist allen Bemühungen um Exzellenz gemein. Vielleicht gibt es hier also wenig Neues, aber bei der Lektüre dieses Buches werden Sie herausgefordert, gute Disziplinen wieder aufzunehmen, die Sie vor langer Zeit der Apathie oder dem Wunsch nach Spontaneität überlassen haben, und einfach “auf Veränderungen zu reagieren”. Leider betrachten wir solche Anliegen meist nicht als wichtige Eckpfeiler der Programmierkunst. Wir geben unseren Code frühzeitig auf, nicht weil er fertig ist, sondern weil sich unser Wertesystem mehr auf das äußere Erscheinungsbild als auf die Substanz dessen, was wir liefern, konzentriert.

Diese Unachtsamkeit kostet uns am Ende: Ein falscher Pfennig taucht immer auf. Die Forschung, weder in der Industrie noch im akademischen Bereich, erniedrigt sich selbst zu dem niedrigen Posten, den Code sauber zu halten. Als ich noch in der Bell Labs Software Production Research Organisation (Produktion, in der Tat!) arbeitete, hatten wir einige Ergebnisse, die zeigten, dass ein konsistenter Einrückungsstil einer der statistisch signifikantesten Indikatoren für eine geringe Fehlerdichte ist. Wir wollen, dass die Architektur oder die Programmiersprache oder ein anderer hochtrabender Begriff die Ursache für Qualität ist; als Leute, deren angebliche Professionalität der Beherrschung von Werkzeugen und hochtrabenden Entwurfsmethoden zu verdanken ist, fühlen wir uns durch den Wert beleidigt, den diese Maschinen in der Fabrikhalle, die Programmierer, durch die einfache konsequente Anwendung eines Einrückungsstils hinzufügen. Um mein eigenes Buch von vor 17 Jahren zu zitieren, ein solcher Stil unterscheidet hervorragende Leistungen von bloßer Kompetenz. Die japanische Weltanschauung versteht den entscheidenden Wert des alltäglichen Arbeiters und, mehr noch, der Entwicklungssysteme, die sich den einfachen, alltäglichen Handlungen dieser Arbeiter verdanken. Qualität ist das Ergebnis von Millionen selbstloser Handlungen der Fürsorge - nicht nur von irgendeiner großartigen Methode, die vom Himmel herabfällt. Dass diese Handlungen einfach sind, bedeutet nicht, dass sie simpel sind, und es bedeutet kaum, dass sie leicht sind. Sie sind jedoch der Stoff, aus dem Größe und vor allem Schönheit in jedem menschlichen Unterfangen gemacht ist. Sie zu ignorieren, bedeutet noch nicht, ganz Mensch zu sein. Natürlich bin ich nach wie vor ein Verfechter des Denkens in größeren Zusammenhängen und insbesondere des Wertes von Architekturansätzen, die auf tiefem Fachwissen und der Nutzbarkeit von Software beruhen. Darum geht es in diesem Buch aber nicht - oder zumindest nicht offensichtlich. Dieses Buch hat eine subtilere Botschaft, deren Tiefgang nicht unterschätzt werden sollte. Es passt zu der aktuellen Sichtweise der wirklich codebasierten Leute wie Peter Sommerlad, Kevlin Henney und Giovanni Asproni. “Der Code ist das Design “ und “Einfacher Code” sind ihre Mantras. Während wir darauf achten müssen, dass die Schnittstelle das Programm ist und dass ihre Strukturen viel über unsere Programmstruktur aussagen, ist es entscheidend, immer wieder die bescheidene Haltung einzunehmen, dass das Design im Code lebt. Und während Nacharbeit in der Fertigungsmetapher zu Kosten führt, führt Nacharbeit im Design zu Wert. Wir sollten unseren Code als die wunderschöne Artikulation edler Designbemühungen betrachten - Design als Prozess, nicht als statischer Endpunkt. Im Code spielen die architektonischen Metriken der Kopplung und Kohäsion eine Rolle. Wenn Sie Larry Constantine zuhören, wie er Kopplung und Kohäsion beschreibt, spricht er in Begriffen des Codes und nicht in hochtrabenden abstrakten Konzepten, die man in der UML finden könnte. Richard Gabriel rät uns in seinem Essay “Abstraction Descant”, dass Abstraktion böse ist. Code ist das Anti-Böse, und sauberer Code ist vielleicht göttlich.

Um auf meine kleine Schachtel Ga-Jol zurückzukommen, halte ich es für wichtig, darauf hinzuweisen, dass die dänische Weisheit uns rät, nicht nur auf kleine Dinge zu achten, sondern auch in kleinen Dingen ehrlich zu sein. Das bedeutet, ehrlich zum Code zu sein, ehrlich zu unseren Kollegen, was den Zustand unseres Codes angeht, und vor allem ehrlich zu uns selbst, was unseren Code angeht. Haben wir unser Bestes getan, um “den Campingplatz sauberer zu verlassen, als wir ihn vorgefunden haben”? Haben wir unseren Code vor dem Einchecken umstrukturiert? Dies sind keine nebensächlichen Anliegen, sondern Anliegen, die im Zentrum der agilen Werte stehen. Es ist eine empfohlene Praxis in Scrum, dass Refactoring Teil des Konzepts von “Done” ist. Weder Architektur noch sauberer Code bestehen auf Perfektion, sondern nur auf Ehrlichkeit und darauf, das Beste zu tun, was wir können. Irren ist menschlich, verzeihen göttlich. In Scrum machen wir alles sichtbar. Wir lüften unsere schmutzige Wäsche. Wir sind ehrlich, was den Zustand unseres Codes angeht, denn Code ist nie perfekt. Wir werden dadurch menschlicher, dem Göttlichen würdiger und kommen dieser Größe in den Details näher.

In unserem Beruf brauchen wir dringend jede Hilfe, die wir bekommen können. Wenn eine saubere Werkstatt die Zahl der Unfälle reduziert und gut organisierte Werkzeuge die Produktivität erhöhen, dann bin ich dafür. Was dieses Buch angeht, so ist es die beste pragmatische Anwendung der Lean-Prinzipien auf Software, die ich je in gedruckter Form gesehen habe. Ich habe nichts anderes von dieser kleinen Gruppe praktisch denkender Menschen erwartet, die sich seit Jahren zusammengefunden hat, um nicht nur besser zu werden, sondern auch ihr Wissen der Branche in Form eines Werks zur Verfügung zu stellen, das Sie nun in Händen halten. Es verlässt die Welt ein wenig besser, als ich sie vorgefunden habe, bevor Onkel Bob mir das Manuskript schickte. Nachdem ich diese Übung in erhabenen Einsichten abgeschlossen habe, gehe ich meinen Schreibtisch aufräumen.

James O. Coplien
Mørdrup, Dänemark