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.