DOAG Deutsche ORACLE-Anwendergruppe e.V.
|  
   

„Viele Entwickler schreiben keinen sauberen Code, weil sie es einfach nicht können“

Jens Schauder ist begeisterter Softwareentwickler und überzeugter „Clean Coder“. Als Keynote-Speaker beim DevCamp 2017 am 8. Februar in Hannover referiert er über Möglichkeiten, in der Praxis sauberen Code zu etablieren. Im Interview mit DOAG Online sprach er über die Herausforderungen und Wege, die Zusammenarbeit im Team zu verbessern.

Herr Schauder, ist Clean Code in der Praxis überhaupt möglich?

Absolut. Wenn man mit Softwareentwicklung Geld verdient, ist sauberer Code unabdingbar. Ansonsten steigen die Entwicklungskosten über kurz oder lang massiv an, das kann sich niemand auf Dauer leisten. Dabei muss man nur zwei Dinge berücksichtigen: Erstens sind „sauber“ und „sauber“ zwei unterschiedliche Dinge. Wenn Sie eine äußerst saubere Küche haben, ist sie für jemanden, der einen Reinraum für die Chip-Produktion braucht, immer noch ein Dreckstall. Genauso ist es mit Code. Wenn Sie einen Import bauen, der einmal produktiv läuft und danach eingestampft wird, sind die Anforderungen andere, als wenn Sie Software schreiben, die Jahrzehnte lang gewartet und weiterentwickelt wird, oder bei deren Ausfall Menschen sterben könnten. Zweitens verdienen viele Entwickler in Wirklichkeit damit Geld, Zeit vor dem Computer zu verbringen. Da ist es dann natürlich vorteilhaft, wenn durch schlecht wartbare Software die Zeit vor dem Computer steigt.

Wie motiviert man ein ganzes Team, sauberen Code zu schreiben?

Die Motivation ist meist nicht so das Problem. Es gibt da das Verhaltensmodell von B.J. Fogg, was ich ganz aufschlussreich finde. Damit Leute etwas tun, müssen drei Dinge zusammen kommen: Fähigkeit, Motivation und ein Auslöser. Wenn ich möchte, dass Entwickler sauberen Code schreiben, muss ich dafür sorgen, dass sie dazu in der Lage sind. Ich muss außerdem dafür sorgen, dass sie es wollen und ich muss ihnen einen Anstoß geben, es zu tun.

Mit welchen Hürden wird man in Firmen häufig konfrontiert?

In meiner Erfahrung schreiben viele Entwickler keinen sauberen Code, weil sie es einfach nicht können. Die Prinzipien von Clean Code sind an sich einfach, sie in die Praxis umzusetzen ist dagegen schwer. Das zu lernen kostet Zeit, macht sich erst nach längerer Zeit bezahlt und der Mehrwert wird nie als Euro-Betrag auf einer Rechnung stehen. Daher werden die Prinzipien in vielen Firmen nicht angemessen gefordert und gefördert. Und in der Ausbildung findet Clean Code meist überhaupt nicht statt.

Es muss also Geld und vor allem Zeit in die Ausbildung der Entwickler gesteckt werden. Aber wenn den Teams wirklich klar gemacht wird, dass Clean Code wertgeschätzt wird, und man zum Beispiel jemanden ins Team bringt, der auf dem Gebiet viel Erfahrung hat und den anderen helfen kann und sie coacht, dann funktioniert das meist ganz gut.

Es gibt ja eine ganze Reihe von Prinzipien, um ordentlichen Code zu erreichen – haben Sie ein Lieblingsprinzip?

Definitiv: das "Single Responsibility Principle“. Wenn jedes Code-Artefakt (Zeile, Methode, Klasse, Package, Jar-File) genau eine Aufgabe hat, und mir als Entwickler diese klar ist, habe ich schon sehr viel erreicht und viele Sachen ergeben sich dann daraus.

Das Problem, gute Namen zu finden, liegt oft darin begründet, dass man nicht weiß, was eigentlich die Aufgabe ist. Wenn Sie eine Klasse ‘HelperUtil‘ finden, wissen Sie zunächst einmal nicht, was sie eigentlich tut. Dem ursprünglichen Autor ist das meist auch nicht klar. Denkt man darüber nach, kommt man oft zu dem Schluss, dass es viele verschiedene Dinge sind, die sich dann auch ordentlich benennen lassen.

Wie gehen Sie vor, wenn Sie die Unordnung von anderen beseitigen müssen?

Wenn die Autoren des Codes noch greifbar sind, vermeide ich es, hinter ihnen aufzuräumen. Das mache ich bei meinen Kindern auch nicht. Stattdessen rede ich mit dem Autor  und wir einigen uns, wie das an der Stelle und in Zukunft besser gemacht werden soll. Dabei ist es wichtig, dass das eine echte Diskussion ist und kein Diktat meinerseits. Wenn jemand zwei Tage an einem Stück Code gearbeitet hat und ich dann nach zehn Minuten Draufschauen sage, "Du musst das so und so machen", wäre das ziemlich vermessen. Was ich aber sagen kann, ist: "Ich finde das verwirrend und es wäre für mich leichter verständlich, wenn es so aussähe."

Was machen Sie, wenn die ursprünglichen Autoren nicht mehr greifbar sind?

Dann wird die Sache interessant und ein wenig zu komplex für diesen Rahmen. Aber im Prinzip sieht der Prozess so aus:

  • Minimale Refactorings, um das Schreiben von Tests zu ermöglichen
  • (Charakterisierungs-)Tests schreiben
  • Code refactoren und dabei neue ordentliche Tests schreiben

Das Ganze sollte dann aber nicht als Hauruck-Aktion für kurze Zeit, sondern mit der "Boy Scout Rule" durchgeführt werden. Das bedeutet: Jedes Mal, wenn ich Code anfasse, um ein Feature zu implementieren, hinterlasse ich ihn ein wenig ordentlicher, als ich ihn vorgefunden habe. Es gibt einen sehr guten Vortrag von Sandro Mancuso zu dem Thema, und natürlich das Buch von Michael Feathers: "Working Effectively with Legacy Code". "The Mikado Method“ von Ola Ellnestam und Daniel Brolund ist ebenfalls ein sehr hilfreiches Werk.

Was erwarten Sie sich vom DevCamp?

Ich bin besonders gespannt auf die Reaktionen zum Thema Clean Code von Entwicklern, die sehr Datenbank-zentrisch unterwegs sind. Datenbanken machen das Testen, Refactoring und damit Clean Code oft sehr schwierig, daher bin ich neugierig, welche Diskussionen sich ergeben.

 

Jens Schauder ist Keynote-Speaker beim DevCamp 2017 in Hannover und wird darüber hinaus als aktiver Teilgeber an der Veranstaltung teilnehmen.