Force Feedback Programming - Clean Code leicht gemacht

Jetzt wird es leichter, Clean Code zu schreiben! Endlich! Denn diese Idee habe ich schon lange mit mir herumgetragen: Force Feedback Programming.

Aber erstmal ein bisschen Hintergrund :-)

Wenn wir etwas verändern wollen, wenn wir etwas Neues lernen wollen, dann brauchen wir Feedback. Wir müssen feststellen, ob wir auf dem richtigen Weg sind.

Wenn wir lernen, Fahrrad zu fahren, entsteht solches Feedback sehr schnell. Die Schwerkraft zerrt konstant an uns, so dass wir unmittelbar merken, ob wir beim Fahrrad fahren noch etwas falsch machen.

Etwas länger dauert es, wenn wir lernen, unsere Schuhe zu binden. Die Schleife mag ordentlich aussehen – doch wenn wir dann eine Stunde gegangen sind, geht unser Schuh vielleicht auf. Das macht es etwas schwerer, eine effektive Schuhbindung zu lernen. (Dass man in dieser Hinsicht auch noch dazu lernen kann, wenn man schon denkt, es zu können, habe ich im letzten Jahr erfahren. Bei einem Outdoor-Seminar hat Lars Konarek mir gezeigt, wie eine echt männliche ;-) Schuhbindung aussieht. Und siehe da... seitdem ist mir wirklich kein Schuh mehr aufgegangen. Danke, Lars!)

Je schneller Feedback also kommt, desto leichter lernen wir. Deshalb können auch so viele Menschen "irgendwie" programmieren. Compiler und sofort gestartetes Programm geben so schnell Feedback, dass man zügig Kompetenz aufbauen kann.

Anders ist es jedoch mit dem sauber Programmieren, mit Clean Code. Das ist viel, viel schwieriger zu lernen. Eben weil das Feedback zur Qualität der Wandelbarkeit des Code sehr spät eintrifft – womöglich ereilt es sogar den Codeautor nicht einmal, sondern seinen Kollegen.

In stark Verzögertem Feedback sehe ich den Hauptgrund dafür, dass Clean Code zwar im Bewusstsein vieler Entwickler angekommen sein mag, allerdings nicht in deren Code. Zwischen Kopf und Hand, zwischen Denken und Tun liegt hier eine lange Leitung.

Deshalb habe ich nach einem Weg gesucht, über das hinauszugehen, was ich mit Stefan Lieser zusammen im Clean Code Developer Wiki zusammengetragen habe. Und auch das, was wir in Trainings der CCD School vermitteln, ist noch zu wenig. Denn selbst mit unserer Methodenidee vom Green Coding im Kopf braucht es dann in der Praxis Feedback, ob man sich auf dem Weg zu guter Anwendung befindet.

Tools wie StyleCop oder Teamscale liefern zwar Feedback, doch auch wieder sehr spät. Wenn Feedback zur Sauberkeit erst bei einem späteren Build oder gar erst in einem Review entsteht, ist das kraftlos.

Pair Programming kann Feedback viel unmittelbarer herstellen. Doch erstens programmiert nicht jeder im Pair. Zweitens ist der Feedbackgeber auch nur ein Mensch ;-) D.h. er kann mit seinem Feedback nachlässig sein, er kann einen geringeren/fluktuierenden Anspruch an Sauberkeit haben, er kann auch Vermeiden, in Konflikt mit dem Partner zu geraten durch wiederholten Hinweis auf Unsauberkeit.

Aber wie denn dann?

Unmittelbares Feedback

IDEs haben inzwischen einen Testrunner eingebaut. Der führt auf Wunsch die Unit Tests im Code aus. Das ist ein schnelles Feedback zur Verhaltenskorrektheit des Codes. Es ist ähnlich schnell, wie das Compilerfeedback zur syntaktischen Korrektheit.

Doch es geht schneller. Intellisense und Hintergrundcompilation geben bereits beim Tippen Feedback zur Verwendung der Programmiersprache. Und Tools wie NCrunch haben diese Schnelligkeit inzwischen auch für Unit Tests hergestellt.

Die Codesauberkeit hingegen... die hinkt immer noch weit hinterher.

Bis jetzt.

Denn nun habe ich mit Robin Sedlaczek eine Visual Studio Extension entwickelt, die die Codesauberkeit unmittelbar spürbar macht, während Sie tippen.

Mit der Force Feedback Programming (FFP) Extension bekommen Sie Feedback auf zwei Sinneskanälen:

• Visuelles Feedback: Die Extension färbt den Rumpf von Methoden nach dem Grad ihrer Sauberkeit ein. Sie sehen auf einen Blick, wie tief das Brownfield ist, durch das sie waten. Nicht kleine Icons am Editorrand oder dezente Striche kennzeichnen Unsauberkeit, sondern der ganze Hintergrund einer Methode.
• Taktiles Feedback: Die Extension macht die Sauberkeit einer Methode fühlbar at your fingertips, indem sie Ihre Tastatureingabe während des Schreibens von Code stört. Je unsauberer Ihr Code, desto häufiger die Störungen. Es fällt Ihnen dadurch immer schwerer, unsauberem Code weitere Unsauberkeit hinzuzufügen.

Derzeit ist die Metrik, die die FFP Extension zur Sauberkeitsbeurteilung heranzieht, sehr, sehr simpel: Sie zählt einfach die Zahl der Zeilen in einer Methode. Angesichts des Ergebnisses eines Experiments von Prof. Dag Sjøberg meine ich jedoch, dass die Zeilenzahl ein (zunächst) guter Startpunkt ist. Unsauberkeit lässt sich ohnehin nicht exakt bestimmen. Es geht um eine Näherung und dann um eine Tendenz. Viel wichtiger als eine genaue Messung von Unsauberkeit ist das Feedback. Wie kann ein Unsauberkeitswert spürbar gemacht werden?

Wenn unsauberer Code die Verständlichkeit bzw. Lesbarkeit beeinflusst, warum dann nicht die Lesbarkeit tatsächlich reduzieren? Deshalb die Einfärbung des Methodenhintergrunds. Der Code wird - je nach Farbschema - immer schwerer zu entziffern. Dazu muss man kein Programmierer oder Domänenexperte sein. Man muss nur hinschauen. Das versteht sogar ein Laie.

Wenn unsauberer Code die Veränderbarkeit beeinflusst, warum dann nicht die unmittelbar reduzieren? Code inhaltlich nur schwer verändern zu können beim Bug Fixing oder für neue Features, ist eine Sache. Diese Schwierigkeit bemerkt nur ein Programmierer. Sie entsteht zunächst auch nur in seinem Kopf. Was aber, wenn es tatsächlich physisch schwieriger wird, den Code zu verändern? Dann muss man nicht erst ein mentales Modell des Codes aufbauen, sondern man spürt beim Tippen, dass es schwieriger wird. Über Farbe kann man hinwegsehen. Doch wenn das Tippen behindert wird, dann nervt Brownfield-Code im Hier und Jetzt.

Das ist die Theorie hinter Force Feedback Programming. Wir brauchen schnelleres Feedback, wenn wir unsere Strukturierungs- und Codierungspraxis ändern wollen. Visuelles und taktiles Feedback sollen helfen, Codesauberkeit unmittelbar spüren zu können.

Das Tool

Mit dieser Theorie bin ich einige Jahre schwanger gegangen. Ich hätte versuchen können, sie selbst umzusetzen... aber irgendwie habe ich es nicht geschafft, über die Hürde des Framework für VS Extensions zu springen. Da lag zu wenig in meiner Expertise als Entwickler. Also habe ich immer wieder nach Kooperationspartnern gesucht. Es hat Interessenten gegeben - doch als es dann ernst wurde mit der Codierung... waren die schnell aus dem Projekt raus.

Nach Lektüre eines Artikels von Robin über die VS Extension Programmierung hatte ich neulich wieder gedacht, da sei ein Kandidat für die Zusammenarbeit. Also habe ich ihn angeschrieben - und dieses Mal sind wir über die Theorie hinausgekommen. Robin ist nun der VS Extension Experte und Codierer, ich bin der Product Owner und Kommunikator :-) Das funktioniert bisher wunderbar. Wir gehen in kleinen Inkrementen stetig vorwärts. Es gibt ein Backlog und noch mehr Ideen. Es gibt ein Github-Repository und einen automatischen Buildprozess.

Noch wichtiger aber für Sie: Es gibt inzwischen eine funktionierende FFP Extension und Sie können die Releases aus dem Repo herunterladen. Ausprobieren ausdrücklich erwünscht :-) (Achtung: Damit eine Installation auch ein Ergebnis zeigt, muss eine Konfigurationsdatei existieren. Lesen Sie hier, was dafür noch zu tun ist.)

Damit Sie aber nicht die Katze im Sack installieren, hier eine Demonstration von Force Feedback Programming mit Stand Juni 2016:

Im Video refaktorisiere ich eine kleine Brownfield-Anwendung. Hier und da kommentiere ich das, aber die eigentliche Refaktorisierung läuft in Zeitraffer ab. Es geht nicht darum, wie ich refaktorisiere, sondern dass ich es tue und dass Sie das insbesondere anhand der Entwicklung der Codefarbe verfolgen können.

Beim Refaktorisieren leitet vor allem das visuelle Feedback. Wenn es um den Einbau von Veränderungen geht, wird auch taktiles Feedback wichtig. Davon ein andermal mehr.

Was halten Sie von der Idee? Probieren Sie die Extension doch einmal aus. Geben Sie uns Feedback hier oder via Gitter.