klarprogrammieren

Neben dem „klarlernen“ gibt es auch das „klarprogrammieren“, eine meiner Wortschöpfungen, die dem Programmieren eine Nuance verleiht, eine Richtung gibt, Reifegrade erkennen lässt. Beim „klarprogrammieren“ geht es um folgende Beobachtungen und Einsichten:

• Programmieren ist wie Schreiben: Klares Schreiben ist besser als verschnörkeltes Schreiben. Diese Ansicht vertrat auch einer der Gründerväter der Informatik, der Stanford-Professor Donald Knuth mit seinem Ansatz „Literate Programming“. Er ging sogar so weit, dass er den Quellcode einiger seiner Programme als Buch publizierte, das von einem renommierten Verlag auch tatsächlich verkauft wurde. Fazit: Quellcode muss gelesen werden und ist daher gut lesbar zu verfassen.
• Klarheit ist gut. Klarheit sollte das Ziel Nr. 1 beim Schreiben ebenso wie beim Programmieren sein, nicht Testabdeckung oder Testgeschwindigkeit oder andere Sekundärziele. Klarheit gibt der Entwicklung eine Trajektorie: Wir wissen, wohin es sich entwickelt.
• Klären (etwas klarer gestalten) ist Wertschöpfung (sowohl im Schreiben als auch im Programmieren). In unserer Zeit wird dies erkannt und die entsprechenden Wertschöpfungsstrukturen und Wertschöpfungsprozesse entdeckt und gestaltet. Z.B. Refactoring als wesentliche Programmiertätigkeit.
• Refactoring ist ein Klärungsprozess in Agilen Vorgehensmodellen. Refactoring ist die Überarbeitung der Namen, Begriffe und der Struktur des Geschriebenen (des Quellcodes), ohne an der Aussage des Textes (der Funktion des Programms) etwas zu ändern. Refactoring kostet Ressourcen ohne neue Aussagen (neue Funktionen) zu liefern und ist daher für das Management unproduktive Arbeit, die man nicht messen kann. Für die Programmierer ist es wertvolle Arbeit, die über die Qualität der eigenen Zukunft und der Zukunft der späteren Weiterentwicklung, wer auch immer diese übernehmen wird, entscheidet. Refactoring ist Wertschöpfung.
• Programmieren ist eher wie Kreatives Schreiben als eine Wissenschaft mit Absolutheitsanspruch. Donald Knuth nannte seine Buchreihe „The Art of Programming“, obwohl er als Wissenschaftler strenge Massstäbe anlegte.
• Wittgenstein: Alles was man schreiben kann, kann man klar schreiben.
• Einstein: Wenn man es noch nicht klar schreiben kann, dann hat man es noch nicht genug verstanden.
• Ein guter Programmierer zu werden ist vergleichbar mit dem Anspruch, ein guter Schriftsteller zu werden.
• Ebenso wie beim Schreiben ist die beste Übung, um ein guter Programmierer zu werden, viel zu programmieren, viel Quellcode zu lesen und dabei immer um Klarheit bemüht zu sein.
• Es geht eher um Gestaltung eines „Noch-Nie-Dagewesenen“ ohne Vorbild, ohne Beschränkung, ohne Gestern — als um Engineering mit bewährten Methoden, altgedienten Bausteinen und jahrzehntelangen Erfahrungswerten nach immer den gleichen Mustern. Konstruktion neuer Software und Brückenbau sind eben doch grundsätzlich unterschiedlich.

Damit soll nicht Willkür Tür und Tor geöffnet werden. Die genannten Argumente sollten nicht dazu missbraucht werden, fehlende Tests zu entschuldigen. Den Wertschöpfungsprozess der Klärung selbst klarer zu strukturieren, Meilensteine zu setzen, Indikatoren zu nennen und messbar zu machen, ist ein großes Ziel. Controller hätten gerne SMART-Kriterien, um messen zu können, ob auch wirklich gearbeitet wurde und ob man dem Ziel der Klarheit näher gekommen sei. Einige Indikatoren sind bekannt (Testüberdeckung, SOLID-Prinzipien, Clean Code Development-Prinzipien, Patterns und Anti-Patterns, Bad Smells), entheben einen jedoch nicht des Selber-Denkens. Da es um Zukunft geht, kann es durchaus sein, dass man sich im eigenen Projekt über manche Grenze, Indikatoren und SMART-Kriterien hinweg setzen muss. Dabei sollte es sich jedoch um eine bewusste Entscheidung handeln.

Die Diskussion ist schon sehr alt und rund um das Thema „TDD is dead“ wieder neu entflammt, siehe „Examining the ‚TDD is Dead‘ Controversy“
by Shane Hastie on Jun 04, 2014.