Eine Programmierer-Weisheit pfeifen die Spatzen vo den Dächern: Wiederhole Dich nicht. Früher habe ich nicht verstanden, wie das effektiv in Notes realisiert werden kann, weil ich gedanklich vor einem Dickicht stand: Multi-Options-Paralyse. Heute bin ich schlauer :-)

Auch für ein Projekt in Notes bietet es sich an, Objekt-Orientierte Analyse und Design durchzuführen. Das Objektmodell kann in LotusScript umgesetzt werden. Wohlgemerkt: Noch sind keine Notes-Dokumente und -Masken im Spiel. In der Business-Logik kommen diese Elemente nicht vor.

Notes-Dokumente kommen erst dann zum tragen, wenn es darum geht, die Daten der Business-Objekte zu speichern. Jedes Business-Objekt hat/ nutzt ein Notes-Dokument, um seine Daten persistent zu machen. Wesentlich ist Kapselung, anschaulich: Business-Klasse A nutzt Business-Klasse B. Beide nutzen Notes-Dokumente als Speicher. Aber NIE darf ein A-Objekt das Notes-Dokument eines B-Objekts nutzen.

Notes-Masken kommen nur als GUI-Elemente für Obacht! Business-Objekte ins Spiel. Die Masken arbeiten nie mit Notes-Dokumenten. So kommt man zu einer “sauberen” Trennung von Datenmodell und dessen Visualisierung. Leider ist es leicht, das falsch zu machen, weil man im Dickicht erkennt, dass Masken und Dokumente zusammengehören.

Ich denke mir das so: Das Objektmodell beschreibt, was wo wie erledigt wird. Speicherung und Visualisierung sind davon unabhängig. In meiner heilen Java-Welt nutze ich vielleicht Hibernate und Eclipses SWT. Und in Notes eben Dokumente und Masken.

Schön, dass auch andere der Meinung sind, dass nur ein fauler Programmierer ein guter ist. Passt zu meinem Credo: Einfach ist besser.

Das meine ich ernst – und bildlich, nicht wörtlich. Wir verstehen die bildliche Rede des Gegenübers im Alltag meistens ohne grosse Anstrengung: “Irgendwie schmerzhaft und trostlos, dazu ein bißchen Pathos”. Funktioniert vermutlich am besten, so lange man sich der Muttersprache bedient und den eigenen Kulturkreis als Grundlage der Interpretation benutzen kann. Wenn ich französische Comics und Zeitungen lese, dann flutschen mir fast alle Metaphern durch – will sagen: ich nehme wörtlich, was bildlich gemeint ist. Mißverständnisse sind mitunter sehr erheiternd.

Das oben beschriebene Bild kam mir, nach dem ich sehr lange sehr … häßlichen … Code bearbeitet hatte.
Exkurs: Oft ist es verlockend, Metaphern zu benutzen – eine Abkürzung, die die Eindringlichkeit nicht verliert. “Häßlich” zu sagen ist einfacher, als all das aufzuzählen, was jenseits der Ästhetik liegt. Nur ein fauler Programmierer … Welche Eigenschaften machen Code zu häßlichem Code? Unlesbarkeit, Unverständlichkeit, Brüchigkeit – Änderungen an einer Stelle sorgen für schwerwiegende Fehler an einer anderen Stelle, die “weit entfernt” ist. Code, der wie ein Text von Hegel ist – bildlich gesprochen gibt es das! Oder scholastisch – mit vielen Wenns und Abers. Klugscheisser mag kein Mensch. Exkurs-Ende.

Wenn ich eine neue Programmiersprache lerne, dann ist in meinem Kopf das Bild von mir als kleines Kind, das im Matsch eine Burg baut. Das rote Schüppchen liegt nahe bei, Hose und Hemd nass und zugeferkelt, Haare und Gesicht voll verkrustetem Schlamm. Die Burg ist nur mit viel elterlichem Wohlwollen oder Phantasie als solche zu erkennen. Nicht effektiv, nicht effizient, nicht von Dauer, Muttern hat wieder Arbeit mit der Wäsche. Nur eins: Ein riesengrosser Spass, der glückliches Lächeln zaubert. Die ersten Zeilen Quelltext in der neuen Sprache sind eine Matschburg.

Putzfimmel

In meinem Handapparat steht das Buch “Clean Code”[2]. “Sauberer” Code ist kein häßlicher Code. “Sauberer” Code ist modular und wiederverwendbar, einfach zu testen, einfach zu ändern, robust, seine Zusammenhänge und Wege lassen sich mühelos offenlegen. “Sauber” ist hier eine Metapher. Mit “sauber” verbinden wir angenehmes und gesundes. Weil Metaphern oft so eindringlich sind, kann man leicht vergessen, darüber nachzudenken – man nimmt sie eben so hin. Denk’ ‘mal an “saubere Trennung” und “Säuberung”. Klingt doch gut, oder. Ja, aber oft hängt damit Schönrederei zusammen. Pars pro toto: Sei Dir bewußt, dass Du Metaphern benutzt. Reflektiere Deine Metaphern gelegentlich. Lass’ Dich von Deinen Metaphern nicht verführen.

Man sollte Metaphern nicht überstrapazieren. Beispiel: Was bekommt man, wenn man “jeden Dreck” entfernt, alles “blitzblank” programmiert, die Sauberkeit auf die Spitze treibt? Der Quelltext hat dann keine “dunklen Ecken” mehr, keine Stellen, bei denen man Gefahr läuft “einen Finger zu verlieren”. Man bekommt keinen keimfreien Code, sondern nur sauberen – die Sauberkeits-Metapher “trägt” hier nicht mehr, sie hilft uns nicht mehr weiter.

Jedes Ansammlung von Quelltext, die mir bisher untergekommen ist, hat “dunkle Ecken”. In der Software-Entwicklung nennt man eine dunkle Ecke “Anti-Pattern”, im Gegensatz zu den “Design-Patterns” der Gang-Of-Four. Leicht verfällt man in Sauberkeitswahn und will alle Anti-Patterns ausputzen. Ich denke heute, dass es falsch ist, eine Neurose hinsichtlich unsauberen Codes zu entwickeln – oder Verhalten zu fördern, das zu einer solchen führt. Neue Programmteile programmiere ich so gut wie möglich. Alte säubere ich, wenn sie in Zusammenhang mit den neuen stehen und – wichtige Einschränkung – mir die Kontrolle des neuen in der Folgezeit erheblich erschweren werden. Schmuddeligen Code sehe und bewerte ich und lasse ihn vorbeigehen, wenn er unwichtig ist. Augenmass ist wichtig.

Das Huhn im Topf

Woran denkst Du, wenn Du “Spaghetti” hörst? An die Anstrengung, sie zu produzieren? Das Paket im Supermarktregal? Oder “carabonara” – gleichauf “bolognese”? Ich kenne keine Studie dazu, aber ich wette, die meisten denken an carabonara/ bolognese. Und haben ein Bild vor Augen, das dem der Wikipedia bei “Spaghetticode” nahe kommt. Denken und Sprache hängen eng zusammen, genauso Denken und Sehen. “Sehen ist glauben”. “You don’t think so? We’ll see.” Spaghetticode ist häßlich, weil verworren. Ich mag Spaghetti-Code: Er sichert mein Auskommen bis zur Rente. Meine Finger hat die Maschine eh’ schon gefressen ;)

Ich habe schon viel Quelltext gesehen – gelesen, durchgeackert. Und viel davon hatte eine je eigene Handschrift. Kommentare, Variablennamen, die Weise der Klammerung, die Aufteilung der Funktionen – das unterscheidet sich von Programmierer zu Programmierer. Einen Eindruck hinterläßt bei mir jeder Code – den sinnlich wahrnehmbaren. Sauberer Code, schöner Code, guter Code – Dem Wahren, Schönen, Guten. Code und Ästhetik. Ich bemühe mich so zu programmieren, dass das Ergebnis ein Jungbrunnen ist, Ambrosia. Auf dass es geschmeidig ineinander greift, wie ein Schweizer Uhrwerk.

Licht

All das, was wir heute mit PCs treiben, ist in unserer Wahrnehmung Lichtjahre entfernt von Schalter-an-Schalter-aus, von 0 und 1, von den grundlegenden Funktionen einer Rechenmaschine. Und doch ist es faktisch genau nur das. Das “Blech”, der “Maschinenraum” des PCs liegt unter etlichen Metapher- Schichten. Mein ehemaliger Kommilitone Dieter J. – Programmierer und SysAdmin – sagte mit einem Augenzwinkern: “Wir sind Magier und haben die Zaubersprüche für die Geister, die in den kleinen schwarzen Kästchen eingesperrt sind.” A.C. Clarke: “Jede ausreichend fortgeschrittene Technologie ist von Zauberei nicht zu unterscheiden”[1]. Damit hält die Mystik wieder Einzug in den Alltag. Einerseits ist es ja ganz angenehm, nicht nur ständig mit “kühler Technik” in Berührung zu kommen. Andererseits möchte ich dringend dazu raten, einen Artikel über Halbaddierer zu lesen[4]. Man kann den PC vermenschlichen, als Abkürzung für technische Details – aber bitte nicht ernst nehmen. Alles, was Du auf dem Bildschirm siehst, ist eine gigantische Ansammlung von 0 und 1.

Programmierern (-lernen) heißt heute, sich in den geekisch-nerdischen Kulturkreis einzufinden, so dass einem die gängigen Metaphern[3] verständlich werden.

[1] http://www.oreilly.de/opensource/magic-cauldron/cauldron.g.magic.html
[2] Robert C. Martin. Clean Code. A Handbook of Agile Software Craftsmanship. Boston, 2009.
[3] Möglicher Ausgangspunkt http://de.wikipedia.org/wiki/Jargon_File
[4] Beispielsweise Gumm, H.P./ Sommer, M.: Einführung in die Informatik. 6., vollständig überarbeitete und erweiterte Auflage. München, Wien 2004. S.431ff