“Mit Code ist es ähnlich wie mit Kunst”

JAXenter: Fangen wir mit einer schwierigen Frage an: Was ist guter Code? Woran kann man diesen messen?

Christoph Meyer: Um mit einem sinngemäßen Zitat von Robert C. Martin zu beginnen: „Mit Code ist es ähnlich wie mit Kunst. Niemand kann dir genau sagen, was ein gutes oder schlechtes Bild ausmacht. Aber wenn ein Betrachter davor steht, wird er es schnell sagen können.“

Es gibt keine klare, einheitliche Definition von gutem Code, jeder Entwickler hat eine andere Vorstellung. Es haben sich aber Merkmale herauskristallisiert, die man in diesem Zusammenhang immer wieder findet. Hier würde ich zuerst Lesbarkeit, Verständlichkeit, Wartbarkeit und Testbarkeit nennen.

Diese Merkmale wiederum sind qualitativ, was die Messbarkeit erschwert. Die statische Codeanalyse liefert hier als Hilfestellung eine Menge Kennzahlen, mit denen man zumindest positive und negative Entwicklungen der Codebasis verfolgen kann. Man sollte sich vorher allerdings gut überlegen, mit welchen Metriken man welche Entwicklungen nachverfolgen möchte und ob die gewählten Metriken auch im Team Akzeptanz finden, wenn man sie zur Steuerung der Codequalität einsetzen will.

JAXenter: Warum ist es so schwer zu beschreiben, was guten Code ausmacht?

Christoph Meyer: Das liegt an den genannten weichen Faktoren, die guten Code definieren. Nehmen wir als Beispiel die Lesbarkeit als Kriterium für guten Code. Lesbarkeit ist beispielsweise abhängig von der gewählten Programmiersprache und ihren Ausdrucksmöglichkeiten aber auch von individuellen Präferenzen der Entwickler. Ich finde es wichtig, dass sich das Team hier auf Standards einigt und diese – wenn möglich – Tool-gestützt oder mit Code Reviews überprüft und einheitlich umsetzt.

Die Betrachtung, dass wir Programmierer Autoren sind, die für eine Leserschaft Text schreiben, finde ich ebenfalls hilfreich. Code wird wesentlich öfter gelesen als geschrieben und mit mangelnder Lesbarkeit verteuern sich Problemanalysen und Bugfixing später enorm.

Was führt zu schlechtem Code?

JAXenter: Welche Faktoren sorgen für schlechten Code, kannst du drei Beispiele nennen?

Christoph Meyer: Zeitdruck, gedankliche Trennung von Funktion und Qualität, sowie fehlendes Feedback.

Zeitdruck hat viele Ursachen und kommt in den meisten Projekten vor. Er wird für mangelnde Qualität gern als Rechtfertigung herangezogen. Zeitdruck ist aber nicht nur Ursache, sondern auch Wirkung: Durch Stress und Zeitdruck entstehen zusätzliche Fehler, die durch „dringende Fehlerbehebungsmaßnahmen“ wiederum Stress erzeugen.

Verstärkt wird das erfahrungsgemäß durch die gedankliche Trennung von Funktion und Qualität. Sagt ein Entwickler einen Satz wie etwa „die Realisierung benötigt X Tage, plus Y Tage für die Unit-Tests und Refactorings“, dann ist das gefährlich, denn die Zahl von Y wird damit aus Managementsicht verhandelbar und kürzbar. Bei testgetriebener Vorgehensweise stellt sich diese Frage erst gar nicht.

Fehlendes Feedback ist tückisch – es lullt ein und wiegt in Sicherheit. Mit Tool-Unterstützung oder Code Reviews kann man hier gegensteuern. Aber der wichtigste Faktor ist sicherlich Collective Code Ownership – wenn sich alle Entwickler im Team gleichermaßen verantwortlich für die Codebasis fühlen, sich mit Pairings helfen und auch Verantwortung für Fehler übernehmen, die aus Code der Anderen stammen, hat man günstige Voraussetzungen für guten Code.

JAXenter: Welche Rolle spielen hier die Softwarearchitekten im Vergleich zu Entwicklern?

Christoph Meyer: Softwarearchitekten als Bindeglied zwischen Entwicklern und Management kommt eine wichtige Rolle zu: Sie definieren den Rahmen für die Entstehung guten Codes, überwachen die Entwicklung kontinuierlich und verteidigen Qualitätsmaßnahmen gegenüber dem Management, während sich die Entwickler auf die Realisierung der Features konzentrieren. Zusätzlich sehe ich beim Architekten auch die Pflicht, für die ausgewählten Qualitätsmaßnahmen Werbung zu machen, zu erklären und zu coachen.

Nach meiner Erfahrung führt das immer wieder zu Konfliktsituationen sowohl mit dem Team, als auch mit dem Management. Die Bearbeitung und Lösung dieser Konflikte ist für mich daher ebenfalls eine wichtige Aufgabe des Softwarearchitekten.

Auf dem Weg zur Clean-Code-Kultur

JAXenter: Auch die Kultur und Stimmung im Unternehmen sind wichtige Faktoren. Wie müssen diese aussehen, damit sie einen positiven Effekt auf die Codequalität haben?

Christoph Meyer: Eine offene und wertschätzende Kommunikationskultur sowie eine konstruktive Problemlösungskultur sind sehr wichtig. Es ist selbstverständlich, dass Fehler passieren und die Frage sollte stets lauten: Wie lösen wir das Problem und wie lernen und verbessern wir uns, damit wir es in Zukunft vermeiden?

Wird im Unternehmen immer zuerst der Schuldige gesucht, führt das zu einer Blame- bzw. Rechtfertigungskultur, in der die Mitarbeiter viel Mühe investieren um nachzuweisen, warum gerade sie nicht Schuld sind. Mir ist aufgefallen, dass ein konstruktiver Umgang mit Problemen in agilen Umfeldern einfacher zu sein scheint. Ich halte so eine Kultur aber auch in „klassischen Umfeldern“ für möglich, beispielsweise durch die Einführung von Feedback-Meetings als abschließenden Teil der Problemlösung oder durch regelmäßiges Zusammentragen von sogenannten Lessons Learned.

JAXenter: Du wirst in deiner Session auch Gamification-Ansätze zeigen – kannst du Beispiele dafür nennen?

Christoph Meyer: Ein gutes Beispiel ist ein Scoring-System, in dem Entwickler etwa Punkte für die Erledigung von Qualitätsmaßnahmen bekommen können. Das kann man mit einem Achievement-System koppeln, wo sich Badges und Titel freischalten lassen. Eingebettet in ein etwas nerdiges Szenario und gekoppelt mit freiwilliger Teilnahme der Entwickler kann man eine Menge Spaß an Refactorings für guten Code entwickeln.

In diesem Sinne: Errungenschaft „Clean Code Padawan“ freigeschaltet!

JAXenter: Vielen Dank für dieses Interview!