#Handwerk: Clean vs. pragmatisch?
3. Mai 2010 - 11:31 UhrAm Beispiel von Thomas’ Blogbeitrag “Null Verständnis” kann man wunderschön zwei Dinge erkennen: Erstens, wie schnell man aus einem praktischen Problem in eine Grundsatzdiskussion abgleiten kann und zweitens, dass es offensichtlich einen Unterschied zwischen möglichst sauberen Vorgehensweisen und pragmatischen Ansätzen geben kann. Oder ist dem nicht so?
Zunächst zum Thema “Grundsatzdiskussion”: Ich persönlich bin kein großer Freund dieser Form von Diskussionen, werden sie doch gerne anhand von vereinfachten Beispielen geführt und nähern sich schnell einem recht grundlegendem Level an, da ab einem gewissen Punkt das Selbstverständnis eines Teils der Diskussionspartner berührt werden könnte. Das beiseite gelassen, eignen sie sich jedoch wundervoll, um unterschiedliche Grundideen auszuarbeiten, wie es in diesem Fall geschehen ist: Auf der einen Seite die Fraktion, die gerne auf null als Rückgabewert von GetXXX-Funktionalitäten verzichten möchte, wenn diese als Parameter einen ID-Wert übergeben bekommen und der Datensatz nicht existiert (Begründung: ID kennzeichnet nun mal einen eindeutig identifizierten Datensatz, gibt es diesen nicht, ist irgendwas faul im Staate Dänemark – das Ganze kann dann wahlweise über ein Null-Objekt oder eine Exception abgebildet werden), auf der anderen Seite die Fraktion, die in diesem Fall eben null zurück gibt und das im Code abfragen und abfangen möchte.
Unabhängig davon, dass ich die Meinungen beider Fraktionen nachvollziehen kann (und dennoch gerne Null-Objekte einsetze, da sie die weitere Verarbeitung stark erleichtern können und oftmals der Wartbarkeit zuträglich sind), haben wir es hier mit einem eher grundsätzlicheren Problem zu tun: Clean Code vs. pragmatische Entwicklung, um es mal zugespitzt zu umschreiben. Dieser Widerspruch ist jedoch bei näherer Betrachtung keiner, jedenfalls soweit es mich betrifft, denn in Wahrheit haben wir es an dieser Stelle eher mit zwei verschiedenen Anforderungsmodellen zu tun:
Beiden Fraktionen geht es um einen möglichst sauberen, wiederverwendbaren und auch für andere Entwickler leicht verständlichen Code. Da sind sich beide einig, der Unterschied liegt darin, ob und wie mit Annahmen außerhalb des DataLayers umgegangen wird:
- Die “Clean Coder” wollen, dass der Code vertrauenswürdig ist, d.h. er soll sich in jedem Fall eindeutig verhalten und außerhalb des Kontextes etwa eines DataLayers keinerlei Annahmen über dessen Struktur und Funktionsweise erfordern. Ich folge diesem Ansatz in der Regel. Das bedeutet für: Null-Objekte, da wo es sinnvoll ist (Benutzer gehören für mich in aller Regel dazu), null bei nicht relevanten Geschichten oder Dingen, die schon ganz eindeutig aussagen, dass es eventuell auch KEIN Ergebnis geben kann (FindXXX-Methoden wäre klassische Kandidaten dafür).
- Die “Pragmatiker” haben einen anderen Schwerpunkt: Sie legen weniger Wert auf die oben angesprochene Vertrauenswürdigkeit von Code, denn die erarbeiteten Lösungen werden entweder meist allein verwendet, oder stellen Lösungen dar, die von einem Endkunden in aller Regel nicht selbstständig weiterentwickelt werden. Hier heißt es: Null statt eines Null-Objekts, denn hier ist außen bekannt, wie das Repository sich verhält und die Anwendungsfälle für etwa Null-Objekte halten sich meist in Grenzen.
Beide Fraktionen haben somit unterschiedliche Anforderungen an Code, der scheinbare Widerspruch zwischen pragmatischem und sauberen Programmieren ist also keiner – wir haben es schlicht mit unterschiedlichen Verwendungsszenarien zu tun.
Ob, und in welchem Umfang man nun die Meinung der einen oder der anderen Fraktion teilen mag, ist eine andere Frage. Ich persönlich tendiere zur Clean Code-Ansicht, denn ich habe für mich die Sinnhaftigkeit von Null-Objekten schon seit geraumer Zeit erkannt. Dementsprechend definiere ich meine Entitäten und meine Schichten auch und kann mich so darauf verlassen, stets eine funktionsfähige Objektinstanz zu besitzen und entsprechend meinen Code einfacher strukturieren. Das Ergebnis: Wartbarkeit und Sicherheit steigen, meine Applikation verhält sich vorhersagbarer, ich kann mindestens ebenso gut testen, wie beim eher “pragmatischen” Ansatz.
Insofern erscheint mir hier der Clean Code-Ansatz im Endeffekt sogar pragmatischer zu sein.
