18. Feb 2016
XITASO Tech Talk: Clean Code

Clean Code – klar das ist jedem ein Begriff. Aber was genau bedeutet das für meine tägliche Arbeit als Entwickler und auf was muss ich eigentlich achten?

Christian Heinrich führt uns an die Thematik Clean Code in seinem Tech Talk heran.

Christian Heinrich, Senior Software-Entwickler im Bereich „Technische Software“
christian.heinrich@xitaso.com

Was genau ist Clean Code?

Der Begriff stammt aus dem gleichnamigen Buch von Robert C. Martin (ISBN: 0132350882). Eine einheitliche Definition zu Clean Code gibt es demnach nicht, wahrscheinlich gibt es so viele Definitionen wie Programmierer, aber fragt man sehr erfahrene und renommierte Entwickler, lässt sich eine Tendenz erkennen:

• Der Code ist elegant und effizient.

• Der Code ist einfach und direkt.

• Die Absicht ist klar erkennbar.

• Der Code macht genau eine Sache, und diese sehr gut.

• Der Code macht genau das, was man erwartet.

• In sauberem Code können sich keine Fehler verstecken.

• Sauberer Code wird von anderen verstanden und kann daher leicht erweitert und geändert werden.

• Der Code ist getestet.

• Es gibt keine offensichtlichen Verbesserungsmöglichkeiten.

Letztendlich geht es darum, die Lesbarkeit des Codes mit allen einem Entwickler zur Verfügung stehenden Mitteln zu optimieren. Es beginnt bei vernünftiger Benennung von Klassen, Methoden und Variablen, über die Formatierung des Codes, sinnvollen Kommentaren, das Beachten der SOLID-Prinzipien bis hin zu einer Kultur, die die Pfandfinder-Regel beherzigt, d.h. verlasse den Code immer sauberer als du ihn vorgefunden hast.

Das gerade erwähnte Akronym SOLID wurde ebenfalls von Robert C. Martin geprägt und steht für:

• Single Responsibility

• Open-Closed

• Liskov Substitution

• Interface Segregation

• Dependency Inversion

Für die Lesbarkeit des Codes gibt es eine einfache Metrik, die in folgender Skizze schön veranschaulicht wird:

http://www.osnews.com/story/19266/WTFs_m

Wie werde ich ein Clean Code Entwickler und warum?

Sauberen Code zu schreiben, muss jedem professionellen Entwickler ein wichtiges Anliegen sein. Es genügt nicht, ein Stück Software zu schreiben, das irgendwie die Funktionalität bietet, die gerade gefordert wird. Vielmehr muss sich der Entwickler immer im Klaren darüber sein, dass das was er schreibt von anderen Entwicklern gelesen wird und von ihnen auch richtig verstanden werden muss. Es ist also schon allein aus Rücksicht und Respekt seinen Entwickler-Kollegen gegenüber notwendig, sprechenden, eleganten, fehlerfreien und getesteten Code zu schreiben.

Die deutschsprachige Initiative für mehr Professionalität in der Softwareentwickler namens „Clean Code Developer“ hat ein eingängiges Stufensystem entworfen, mit dem sich jeder Softwareentwickler Schritt für Schritt die wichtigsten Grundsätze aneignen kann (http://clean-code-developer.de/). Zudem definieren sie ein Wertesystem, das aus den folgenden vier Werten besteht:

• Evolvierbarkeit

• Korrektheit

• Produktionseffizienz

• Kontinuierliche Verbesserung

Bei XITASO ist die Code Review eines jeden Entwicklungstasks fester Bestandteil des Entwicklungsprozesses. Hier ist jedes Teammitglied gefordert, den Quellcode des Kollegen zu begutachten und Feedback zu geben. Durch diese Reviews geben sich die Teammitglieder gegenseitig Verbesserungsvorschläge und es entwickelt sich auch ein gemeinsames Verständnis für sauberen Quellcode. Von diesen kurzen Feedback-Schleifen profitieren gerade die weniger erfahrenen Kollegen, aber auch die senioren Entwickler sind ständig gefordert, ihre Softwarepraktiken zu verbessern.

Gerade mit der Erfahrung kommt auch das richtige Gespür dafür, wann der Code nun sauber ist. Man muss sich gerade als professioneller Softwareentwickler immer hinterfragen, ob der Aufwand zu einem vernünftigen Verhältnis zum Nutzen steht. Das ist immer eine Gratwanderung. Der Kunde steht immer im Mittelpunkt unseres Tuns, denn ohne ihn hätte wir nichts zu tun. Der Kunde profitiert ständig von Clean Code, da er fehlerfrei, getestet, leicht erweiterbar, schnell änderbar und wiederverwendbar ist, und nur dadurch ist es möglich schnell und effizient Software zu entwickeln, auch wenn es im ersten Moment so aussieht, als ob Clean Code mehr Zeit in Anspruch nehmen würde.

Welche Themenbereiche sind wichtig?

Die Wichtigkeit der Themenbereiche variiert von Projekt zu Projekt, aber auch von Team zu Team. Ich denke, dass alle der folgenden Themen unter den Entwicklern diskutiert werden sollten, um ein gemeinsames Verständnis für Clean Code zu schaffen.

• Aussagekräftige Namen
  • Die Namen von Variablen, Methoden und Klassen müssen sprechend sein
  • Eine Bezeichnung für ein Konzept ist sinnvoll

• Funktionen
  • sollten klein sein
  • genau eine Aufgabe erfüllen
  • auf einer Abstraktionsebene sein

• Kommentare
  • Dürfen kein Ersatz für schlechten Code sein
  • Müssen für alle public Methoden erstellt werden
  • Müssen aktuell sein

• Objekte und Datenstrukturen

• Fehler-Handling

• Grenzen

• Unit-Tests
  • Alle public Methoden müssen getestet werden
  • Nur ein Assert pro Test
  • Test Drive Development (https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung)
    • Schreibe Tests für das erwünschte fehlerfreie Verhalten, für schon bekannte Fehlschläge oder für das nächste Teilstück an Funktionalität, das neu implementiert werden soll. Diese Tests werden vom bestehenden Programmcode erst einmal nicht erfüllt bzw. es gibt diesen noch gar nicht.
    • Ändere/schreibe den Programmcode mit möglichst wenig Aufwand, bis nach dem anschließend angestoßenen Testdurchlauf alle Tests bestanden werden.
    • Räume dann im Code auf (Refactoring): Entferne Wiederholungen (Code-Duplizierung), abstrahiere wo nötig, richte ihn nach den verbindlichen Code-Konventionen aus etc. Natürlich wieder mit abschließendem Testen. Ziel des Aufräumens ist es, den Code schlicht und verständlich zu machen.
  • Tests sollen F.I.R.S.T. sein:
    • Fast – schnell in der Ausführung, so dass sie oft ausgeführt werden können
    • Independent Isolated – ein fehlschlagender Test darf keinen anderen Test beeinflussen; die Reihenfolge der Testausführung muss irrelevant sein)
    • Repeatable – der Test muss überall ausführbar sein, z.B. auf Buildserver, lokaler Laptop – ohne Netzwerkverbindung
    • Self-Validating – Ergebnis ist entweder true oder false.
    • Timely – Schreibe erst den Test, dann den Produktionscode

• Klassen
  • Müssen klein sein
  • Starke Kohäsion notwendig
  • Genau eine Aufgabe pro Klasse – Single-Responsibility-Prinzip

• Emergenz
  • Nach Kent Beck kann ein gutes Design durch vier grundlegende Regeln erstellt werden:
  • Ein einfaches Design:
    • Besteht alle TestsE
    • Enthält keine Duplikate
    • Drückt die Intention des Entwicklers aus
    • Minimiert die Anzahl der Klassen und Methoden (zeilenmäßig)

• Schrittweise Verfeinerung
  • Der Code darf niemals anfangen zu verrotten
  • Boy-Scout-Regel: verlasse den Code immer sauberer als du ihn vorgefunden hast
  • Broken-Window-Theorie: ist bei einem Haus schon ein Fenster eingeworfen worden, sinkt die Hemmschwelle ein weiteres Fenster einzuwerfen drastisch.