Uncle Bob: "Nichts geschieht in der heutigen Gesellschaft ohne Software"

Inhaltsverzeichnis

Uncle Bob, der mit bürgerlichem Namen Robert Cecil Martin heißt, gilt als Vater von Clean Code. In Trainings vermittelt er den Teilnehmern, wie sie unter anderem mit testgetriebener Entwicklung bessere Software und sauberen Code schreiben. heise Developer traf ihn im Rahmen eines solchen Trainings, das er bei der Lebensversicherung LV 1871 in München gegeben hat.

heise Developer: Uncle Bob, Sie gelten als Vater des Clean Code. Wann ist aus Ihrer Sicht Code sauber?

Uncle Bob: Sorgfalt macht Code sauber. Entwickler sollen die Menschen, die ihren Code lesen, wichtig nehmen, ebenso die Anwender, die ihn benutzen und den Arbeitgeber, der sie dafür bezahlt. Sie sollen ihren Code so verständlich, lesbar und veränderbar wie eben möglich schreiben. Das macht Clean Code aus – ich könnte eine Reihe von Disziplinen aufzählen, aber diese Sorgfalt ist die Kerntugend.

heise Developer: Als wir im Dezember Martin Folwer interviewt haben, sagte er: "Refactoring ist heute relevanter als vor zwanzig Jahren". Sehen Sie das bei Clean Code ebenso?

Uncle Bob: Ja, Refactoring ist wichtiger als früher und Clean Code ebenso, weil die Probleme größer geworden sind. Es gibt viel mehr Software als damals. Der geschriebene Code wächst exponentiell. Unsere Gesellschaft hängt mehr und mehr von diesem Code ab.

Die meisten Leute begreifen nicht, dass Entwickler hinter allem sind. Nichts geschieht in der heutigen Gesellschaft ohne Software: Sie können nicht telefonieren, Auto fahren oder etwas verkaufen. Kein Gesetz wird angenommen oder durchgesetzt. Software ist überall. Kaum jemand versteht das bisher. Das heißt natürlich: Wenn Software schlecht ist, hat das enorme Auswirkungen.

Das war nicht immer so: In den 60-er und 70-er Jahren gab es hier und da Software, aber eben nicht überall. Heutzutage schreibt jemand Code für ein Thermostat. Wenn dieser Code angreifbar ist und Hacker Zugriff auf tausende Geräte erlangen, können sie es als Waffe verwenden und beispielsweise Denial-of-Service-Angriffe durchführen.

Ein Softwarefehler kann große Flughäfen lahmlegen oder für Flugzeugabstürze verantwortlich sein. Dabei war es nicht einmal ein Software-, sondern ein Spezifikationsfehler, aber jetzt gibt es einige hundert Tote. Ich hasse es, dafür Software allein verantwortlich zu machen, aber wenn die Softwareverantwortlichen die Risiken im Vorfeld benannt und erklärt hätten, wäre es vielleicht anders ausgegangen.

Und das wird in Zukunft noch schlimmer: Irgendwann könnte ein Softwarefehler Tausende Menschen töten – mit einem Mal. Also ja, sauberer Code ist deutlich wichtiger als vor zwanzig Jahren.

Überzeugungsarbeit leisten

heise Developer: Wie überzeugen Sie jemanden, der sagt "If it ain't broke, don't fix it"?

Uncle Bob: Die Frage wird mir immer wieder gestellt: Wie überzeugt man Manager und andere Entwickler? Wie überzeugt man Menschen, die auf ein anderes Wertesystem setzen und es nicht ändern möchten, da ihre Karriere darauf aufbaut?

Es gibt kein Wundermittel, aber ich hoffe, dass wir unsere Arbeitsweise ändern, bevor Regierungen es für uns erledigen. Ich hoffe, wir haben noch genügend Zeit, dass Gruppen wie die Agile Alliance die Idee in der Entwicklergemeinde vorantreiben und genügend Unterstützer finden. Sonst kommt irgendwann jemand von außen und sagt: "Ihr seid außer Kontrolle".

heise Developer: Wenn ich als Entwickler von testgetriebender Entwicklung (Test Driven Development, TDD) überzeugt bin: Wie erkläre ich meinen Vorgesetzen, dass die von außen zunächst chaotisch erscheinende Vorgehensweise die richtige ist?

Uncle Bob: Sie sagen es ihnen nicht, und es geht sie nichts an. Wir sind die Programmierer und entscheiden, wie wir arbeiten. Wir sind Fachleute. Unser Vorgesetzen müssen uns vertrauen, dass wir die Best Practices verwenden, um unseren Job zu machen. Aber ich werde nicht zu einem Manager gehen und fragen: "Ist es OK, wenn ich Tests schreibe?", denn damit wälze ich das Risiko auf sie oder ihn ab. Und das ist nicht fair.

heise Developer: Wie kann es umgekehrt funktionieren, wenn Manager den Nutzen von TDD verstanden haben und ihre Entwickler überzeugen wollen, die das womöglich zunächst lästig finden und den Nutzen nicht erkennen?

Uncle Bob: Auch die Frage kriege ich häufig gestellt, und es gibt kein Wundermittel. Manager sollten Entwicklern nicht sagen, wie sie ihren Job zu erledigen haben beziehungsweise ihnen TDD oder Pair Programming vorschreiben.

Dazu haben Manager kein Recht, aber sie haben das Recht, die passenden Ergebnisse zu erwarten. Und das ist ein Weg: Manager können ihren Teams sagen: "Mir ist egal, wie ihr es macht, aber ihr müsst nachweisen können, dass die Software auf Knopfdruck funktioniert". Diese Erwartung ist angemessen und entspricht auch der, die Anwender an die Software haben.

Auch haben Manager das Recht von ihren Entwicklern zu fordern, dass sie ersetzbar sind, wenn sie krank werden oder das Unternehmen verlassen. Ob die Programmierer das mit Pair Programming umsetzen oder anders, bleibt ihnen überlassen.

Diese Erwartungen sind fair und es bleibt uns Programmierern überlassen, herauszufinden, wie wir sie erfüllen. Und meine Vermutung ist, dass die meisten den offensichtlichen Ansatz nehmen und sich TDD, Pair Programming und Refactoring zuwenden. Wenn sie eine für sie bessere Lösungen finden, ist es ebenso gut.

heise Developer: Haben wir aus den Fehlern der Vergangenheit gelernt? Ist heute geschriebener Code zukunftssicherer als schwer durchschaubarer Legacy-Code, oder ist der Code von heute der Legacy-Code von morgen, wenn wir es nicht richtig angehen?

Uncle Bob: Das ist nach wie vor ein großes Problem und zwar eins, das quasi jeder hat. Der heutige Code wird dieselben Probleme bringen wie der alte, mit dem wir uns rumschlagen müssen. Wahrscheinlich wird es sogar schlimmer. Ich vermute, dass ein Großteil des heutigen Codes in der Zukunft zu Legacy-Code wird – vermutlich um die 80 Prozent. Die gute Nachricht daran: 20 Prozent werden es nicht, und ich bin zuversichtlich, dass dieser Anteil wachsen wird.

Einstieg in TDD

heise Developer: Wie machen Entwickler ihre ersten Schritte mit testgetriebener Entwicklung?

Uncle Bob: Sehr vorsichtig! Es ist eine Fertigkeit, nicht nur eine Reihe von Regeln. Man muss TDD üben und richtig lernen, bevor man damit ernsthaft arbeiten kann. Es kommt häufig vor, dass jemand die drei Grundregeln von TDD lernt und gleich damit arbeitet. Dann fangen die Probleme an, es wird kompliziert, und die Betroffenen verwerfen TDD.

Es braucht einen sicheren Weg, testgetriebene Entwicklung zu üben. Lunch-and-Learn-Events, Dojos, Wochenendtrainings – Entwickler müssen zunächst die Fertigkeit lernen, bevor sie TDD produktiv einsetzen können. Es erfordert von Programmierern und den Unternehmen anfänglich zeitliche Investition, aber anders funktioniert es nicht.

heise Developer: Im heutigen Trainingsprogramm haben Sie testgetriebene Entwicklung mit doppelter Buchführung verglichen. Warum ist TDD für Entwickler so viel schwerer als doppelte Buchführung für Buchhalter?

Uncle Bob: Es ist nicht schwieriger, aber Buchhalter lernen doppelte Buchführung von Anbeginn ihrer Ausbildung. Sie haben keine Wahl, und kein Buchhalter wird erwägen, darauf zu verzichten. Programmierer bekommen dieses Training noch nicht.

Doppelte Buchführung wurde zwar bereits vor 1000 Jahren erfunden, aber das letzte Land, dass es offiziell eingeführt hat, wartete damit bis 1945. Es hat also sehr lange gebraucht, bis die Methodik ihren Weg rund um den Globus zu der Disziplin für Buchhalter gefunden hat.

Ich fürchte, dass wir keine 1000 Jahre Zeit haben, um TDD weltweit durchzusetzen. Aber ich bin zuversichtlich. Sie existiert erst seit zwanzig Jahren und hat sich seitdem gut verbreitet. Ich hoffe und glaube, dass die Verbreitung voranschreiten wird.

heise Developer: Werden Kommentare mit Clean Code überflüssig? Sätze wie "das muss ich später fixen" oder "Folgende Zeile funktioniert, auch wenn ich nicht weiß, wieso" sollte es in TDD freilich nicht mehr geben, aber was ist mit erklärenden Kommentaren für andere Entwickler?

Uncle Bob: Meine Regel für Kommentare ist: Man schreibt einen Kommentar, wenn man nicht in der Lage ist, sich deutlich über den Code auszudrücken. Man sollte immer als erste Option versuchen, aussagekräftigen Code zu schreiben. Kommentare sind die letzte Option. So gesehen sind Kommentare immer ein Zeichen des Scheiterns und man sollte sie als solches sehen.

Schreibe ich selbst Kommentare? Natürlich, aber das zeigt, dass ich an den Stellen nicht in der Lage war, mich ausreichend über den Code auszudrücken. Ich möchte keinen Standard, der vorsieht, dass alles kommentiert werden muss – jede Klasse, jede Methode, jede Variable. Das ist Verschwendung und führt zu Wirrwarr. Kommentare sollten nur dort stehen, wo Entwickler festgestellt haben: Hier kann ich mich nicht deutlich genug durch den Code ausdrücken.

heise Developer: Wie beeinflusst die Open-Source-Entwicklung den Prozess? Lässt sich Clean Code einfacher oder schwerer in der Community durchsetzen als im Unternehmen?

Uncle Bob: Die Open-Source-Community ist sehr interessant, weil sie aus den Committern und den Kontributoren besteht. Erstere bestimmen, ob der Code von Letzteren es ins Projekt schafft. Die Committer legen also die Standards fest. Ich habe an einigen Open-Source-Projekten mitgearbeitet, und gelegentlich haben Committer meine Codeeinreichungen mit dem Argument abgelehnt, dass mein Code nicht dem Standard im Projekt entspräche.

Das ist ein leistungsfähiger Steuerungsvorgang, und ich wünschte, dass mehr Firmen auf dieselbe Art arbeiten würden. Es wäre klug, wenn erfahrene Entwickler dort die Rolle der Committer einnähmen. So ließen sich auch dort Standards besser durchsetzen.

Agile Manifesto: Eine Entstehungsgeschichte

heise Developer:Sie gehören zu den Verfassern des Agile Manifesto. Können Sie uns erzählen, wie Sie dazu kamen und wie Sie die Entstehung erlebt haben?

Uncle Bob: Meine Version der Geschichte ist folgende: Ich war damals seit längerer Zeit als Consultant tätig. Ich unterrichtete C++ und beriet Kunden über objektorientiertes Design. Die Klienten meinten zu mir: Wir brauchen einen Prozess. Bei meinen Recherchen zum Thema stieß ich auf Kent Beck, den ich von früher kannte, und den ich zufällig in München wiedertraf. Ich sprach ihn auf seine Abhandlungen zu Extreme Programming an. Wir organisierten im Anschluss gemeinsam Kurse dazu.

Im Jahr 2000 hatte Kent die Idee, eine Reihe von Leuten zusammenzutrommeln und mit ihnen die sogenannte Extreme Leadership Conference abzuhalten. Neben mir und einigen anderen Leuten waren dort viele Teilnehmer aus der Patterns-Community. Wir trafen uns in der Nähe von Kents Haus und haben erwogen, eine Organisation ins Leben zu rufen. Die große Mehrheit der Teilnehmer wollte das jedoch nicht.

Ich wollte eine solche Gruppe gestalten, jedoch kamen wir zu keinem Ergebnis. Aber im Anschluss sprach mich Martin Fowler an, und wir kamen zu dem Schluss, dass wir ein neues Treffen organisieren sollten, aber mit anderen Leuten wie Ken Schwaber und Jeff Sutherland. Martin und ich verschickten Einladungen. Alistair Cockburn antwortete prompt, dass er ohnehin vorhatte, eine solche Gruppe zu gründen. So nahmen wir seine Teilnehmervorschläge noch auf, und er kümmerte sich um die Organisation des Treffens. Tatsächlich folgten fast alle der Einladung. Nennenswerte Ausnahmen sind Grady Booch und Ivar Jacobsons Tochter Agneta.

Das Treffen, das dann folgte, war eins der spannendsten Meetings meines Lebens. Wir redeten und redeten, aber irgendwie kamen wir zu keinem Ergebnis, obwohl alle Teilnehmer großes Interesse am Thema hatten.

Ich weiß nicht mehr genau, wann es passierte – manche sagen, es war am zweiten Tag, manche, es war am Ende des ersten – jedenfalls schrieb jemand die vier wichtigen Zeilen auf, die noch heute das Manifesto bestimmen und im Kern besagten: "Uns stören die alten Werte nicht, aber wir schätzen die anderen etwas mehr.".

Keiner weiß, wer die Zeilen aufgeschrieben hat, aber genau das war es. Dann gab es noch ein wenig Feinschliff zu erledigen wie einen passenden Namen zu finden. Ich wollte es "leichtgewichtig" nennen – alle anderen hassten das. "adaptiv" wurde ebenso verworfen. Ich glaube, Jon Kern brachte dann "agil" ins Spiel, ein Ausdruck, der beim Militär hoch im Kurs stand. So richtig begeistert war keiner, aber das Wort hat bei der Abstimmung knapp gewonnen.

Ward Cunningham sagte, er würde das Agile Manifesto auf seine Website nehmen und es Leute unterzeichnen lassen. Wir sagten "Mach nur!" und lachten. Aber dann haben tausende Menschen das Manifesto unterzeichnet.

Der erste Computer von Uncle Bob

heise Developer: Kommen wir noch zu etwas ganz anderem: Was sind aktuell Ihre Lieblingsprogrammiersprachen?

Uncle Bob: Derzeit ist meine Lieblingssprache Clojure. Ich bin erst vor acht Jahren über Lisp gestolpert, und ich fand die Sprache fast absurd einfach. Sie hat fast keine Syntax, während ich sehr Syntax-lastige Sprachen gewohnt war. Gleichzeitig ist die Sprache sehr mächtig, was mich zu einem Fan von Lisp allgemein und Clojure im Speziellen gemacht hat.

Zuvor habe ich Java genutzt und setze es immer noch ein. Davor habe ich in C++ und davor in C programmiert. Im Rückblick ist das also eine recht normale Entwicklung.

heise Developer: Wie sind Sie ursprünglich zum Programmieren gekommen?

Uncle Bob: Meine Mutter hatte mir einen Plastikcomputer gekauft, als ich zwölf war, also 1964. Er hatte drei Flipflops und sechs Gates. Alles war mechanisch, und es war ein Dreibit-System: Es konnte zählen, addieren, subtrahieren – kleine Dinge, die man mit drei Bit anstellen konnte. Und die Maschine faszinierte mich. Ich habe Stunden damit verbracht. Ich habe mir dann die erweiterte Anleitung schicken lassen und mein erstes Programm zum Laufen bekommen. Das hat mich so fasziniert, dass ich so etwas für den Rest meines Lebens machen wollte.

heise Developer: Gibt es Programmiersprachen, in denen das Schreiben von Clean Code besonders einfach oder schwer ist?

Uncle Bob: Ich glaube nicht, dass die Programmiersprache einen großen Unterschied macht. Nun gut, vielleicht mit Ausnahme von Cobol. Ansonsten gilt wie gesagt, dass Clean Code eine Frage der Sorgfalt ist. Und wenn Sie sauberen Code lesen, sehen Sie, dass jemand sorgfältig gearbeitet hat.

Trotzdem sind einige Sprachen "sauberer" als andere. Cobol ist keine saubere Sprache, Java ist relativ sauber. Clojure ist eine äußerst saubere Programmiersprache.

heise Developer: Zum Abschluss: Was geben Sie Entwicklern mit? Worauf sollen sie besonders achten?

Uncle Bob: Auch diese Frage wird mir oft gestellt. Zunächst einmal gibt es einige technische Dinge – es gibt viel zu lernen: Die Fähigkeit, Code zu schreiben, Tests zu verfassen und ordentliche Refactorings vorzunehmen. Es gibt Wissen aus den 60-er und 70-er Jahren, das viele Entwickler heute leider ignorieren. Grundsätzlich sollten Programmierer lernen, intensiv zu lesen und zu lernen. Nicht nur Programmiersprachen, sondern auch die Geschichte dahinter.

Außerdem müssen Entwickler das Schreiben lernen. Daran scheitern viele Programmierer. Ich rede nicht von Code, sondern von Abhandlungen, Leitartikeln, Blogs. Leider tun sich einige Programmierer schwer damit, mit anderen Menschen zu kommunizieren, während sie mit Maschinen sehr gut kommunizieren können. Sie müssen lernen, anderen ihre Gedanken zu vermitteln.

Und schließlich müssen sie Sorgfalt lernen und erkennen, welche Dinge sie wichtig nehmen. Dabei geht es nicht nur um die technische Qualität ihres Codes, sondern auch um ihr Business-Umfeld. Das ist wichtig, um die Zusammenhänge zu verstehen.

Ihre wichtigste Aufgabe ist, Code zu schreiben, den andere Programmierer verstehen. Viele denken, das Wichtigste sei, dass der Code läuft, aber es ist viel wichtiger, dass andere Entwickler den Code am Laufen halten können.

Das Interview führte Rainald Menge-Sonnentag, Redakteur von heise Developer.

Siehe dazu auf heise Developer:

• Funktionsweise und Zusatznutzen von Strict TDD

(rme)