Kolumne

Knigge für Softwarearchitekten: Der Schmutzfink

Peter Hruschka, Gernot Starke

©shutterstock.com/StockPhotosLV

Diese Folge unserer Kolumne handelt von Schmutzfinken, einer Spezies, die so alt ist wie das Programmieren selbst. Sie besitzen einen überaus starken Überlebenswillen und lassen sich auch durch Technologiewechsel nicht aus ihrem Konzept bringen. Im Gegenteil: Mit jeder neuen Technologie, Programmiersprache oder Framework entdecken Schmutzfinken neue und kreative Möglichkeiten, ihrer Passion zu frönen.

Robert Martin hat mit seinem Clean Code den (vergeblichen) Versuch der Ausrottung gestartet, aber die Protagonisten dieser Folge überleben jegliche Art der Missionierung, sind sozusagen gegen besseres Wissen immun.

Namen – nur Schall und Rauch

Wie im ersten Programmierkurs nennen Schmutzfinken die Dinge gerne kurz. i, j, x und y eignen sich als Namen hervorragend, ob Businessdaten oder Statusinformation; kürzer als einbuchstabig geht leider nicht. Und in der Kürze liegt die Würze. Statt lange Zeit in das Erfinden fachlich passender Bezeichner zu investieren, halten wir uns an etablierte Kurzformen und schaffen dadurch knackig kompakten Code. Das gilt natürlich sowohl für Variablen, Attribute sowie Funktionen oder Methoden.

Das Böse ist modular

Nur solche Menschen modularisieren, die zuhause warm duschen oder im Winter eine Heizung benutzen. Richtige Entwickler zentralisieren Logik und Daten in möglichst wenigen Dateien. Funktionen oder Methoden sind schon Modularisierung genug, was braucht der schmutzige Fink dazu noch weitere Klassen. Und neumodischer Kram wie OSGI oder Schnittstellenversionierung macht das Leben nur unnötig kompliziert. Zusammen, was zusammen gehört – alle Funktionen oder Methoden einer Applikation gehören einfach in eine Datei.

Schmutzfink

#define private public

Nun, Sie benötigen etwas Kenntnisse in C oder C++, um diesen großartigen Ratschlag so richtig würdigen zu können: In diesen Sprachen verarbeitet ein so genannter Präprozessor den Quellcode, bevor ihn der Compiler zu sehen bekommt. Die #define X Y-Direktive bedeutet, dass sämtliche Zeichenketten „X“ durch „Y“ ersetzt werden.

Super ist, dass Sie diese Präprozessordirektive in eine unbedeutende Headerdatei schreiben können (etwa in license.txt), die Sie dann mittels #include license.txt inkludieren.

Das errät niemand – und auf einen Streich werden Sie sämtliche lästigen „privaten“ Definitionen los – und können das leidige Geheimnisprinzip ad acta legen: Endlich stehen Ihnen wieder private Methoden an Schnittstellen zur Verfügung. No more privacy, no more secrets.

Anmerkung Gernot: Mitte der Neunzigerjahre hat mir der Entwickler einer seinerzeit bekannten CORBA-Middleware in einem Kurs beibringen wollen, das sei „die einzige Methode, wie man mit diesem System ordentlich programmieren könne.“ Ein objektorientierter Broker-Schmutzfink.

N2T-Prinzip

Was, diese Abkürzung kennen Sie nicht? Nur Tester testen. Wer denn sonst – denn testen ist im Auge des stolzen Schmutzfinks eine würdelose Aufgabe, so destruktiv. Lieber konstruktiv programmieren und das Testen dann dorthin verbannen, wo es schon immer war: (sehr) kurz vor der Auslieferung.

N2T bedeutet, dass sich Schmutzfinken während der Entwicklung auf das Schreiben von Quellcode konzentrieren können – und nicht durch lästige Rückmeldungen über korrekt oder inkorrekt abgelenkt werden. Wahre Genies sollen nämlich ungestört und kreativ schaffen können, jegliche Ablenkung unterbricht den geistigen Fluss.

Außerdem wird nach Ansicht der Schmutzfinken die Bedeutung der Farbe „grün“ als Motivator deutlich überbewertet … und dieser Humbug von Test-driven passt ja nur für Übungsbeispiele aus dem Programmierkurs. Esoterischer Kram für Anfänger.

Datentypmonokultur

Es gibt nur drei sinnvolle Datentypen: String, Long und Array. Alles Weitere lässt sich darauf zurückführen und bedeutet überschüssigen Ballast. Wahrheitswerte? In der Programmierbibel steht, wie’s geht: Null ist falsch, alles andere wahr. Aufzählungstypen: überflüssig. Fachliche Datentypen: funktionieren prima über Array von Strings. Das können wir wenigstens in einer bewährten for-Schleife durchlaufen und es ist schön generisch.

Apropos Schleife: Schon lange sind Iteratoren und Collections bei wahren Schmutzfinken verpönt.

Big is beautiful

In langen Funktionen oder Methoden steht alles, was der Schmutzfink über diese Methode wissen muss – kein lästiges Hin- und Herspringen, kein Verfolgen von Aufrufketten. Diese Vorschläge, höchstens eine Bildschirmseite voll (oder gar noch kürzer, wie Robert Martin fordert) sind höchstens für Menschen mit schwachem Kurzzeitgedächtnis, aber nicht für echte Entwickler.

Wahrhafte Schmutzfinken dehnen diesen Ansatz der „umfangreichen Methoden“ direkt auf Klassen aus (sofern sie denn überhaupt in OO-Sprachen arbeiten): Eine Klasse, beispielsweise Server.java, genügt für mittelgroße Systeme in jedem Fall. Auch da haben wir wieder schöne Kohäsion: Es steht alles, wirklich alles, zusammen, was zusammen gehört (o.k. – möglicherweise noch einiges mehr – aber das ist Erbsenzählerei).

Wenn wir dann noch alle Methoden/Funktionen und Deklarationen schön alphabetisch sortieren, kann nichts mehr schief gehen.

Zwei-Augen-Prinzip

Zwei Augen genügen. Immer. Sonst redet dem Schmutzfink ja nur jemand anderes unnötigerweise rein – und unterbricht unter Umständen den kontinuierlichen Ausfluss der Komplexität, ähm Genialität. Allein programmiert es sich immer noch am besten. Außerdem sitzt mir ja der Computer gegenüber, der hilft in Krisen zuverlässig und kompetent weiter.

Früher war alles besser

Da gab es die struct-Definition und nicht diesen ganzen aufwändigen Klassenkram. Da war Performance in die Sprache eingebaut, und wir konnten mit malloc unseren wertvollen Speicher selbst verwalten. Außerdem ist make schneller als Maven und Co – und in so ein schickes make-File können wir mit autoconf so richtig schön portabel implementieren. Ja, zugegeben – selbst unter den schmutzigsten Finken gilt das als hohe Schule, aber es funktioniert. Was für Linus und den Linux-Kernel gut ist, muss für uns erst recht passen.

Außerdem brauchen wir garantiert keine neuen Idiome, Sprachen oder Frameworks. Umgewöhnen oder Neues lernen kostet nur unnötig Zeit (die geneigte Schmutzfinken vermutlich lieber vor dem Debugger schwitzen, um ihre eigene Sauce endlich zu verstehen).

Fazit

Schmutzfinken können Code schnell schreiben, den andere Menschen nur sehr langsam (wenn überhaupt) lesen können. Das hilft kurzfristig bei der Sicherung des Jobs, führt langfristig zu jede Menge Ärger – mindestens mit denen, die den schmutzigen Code erweitern oder ändern müssen.

Noch mehr Knigge gefällig? Dann werfen Sie einen Blick auf die letzte Folge „Der Kammerjäger“.

Aufmacherbild: Mud race runners von Shutterstock / Urheberrecht: StockPhotosLV

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: