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. Es gibt auch eine Beispieldatei.)

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.

 

Posted in Deutsche Beiträge and tagged .

21 Comments

  1. Super idea, Ralf!
    Looks very promising and I am definitely going to try it out.

  2. Ich hab das Tool mal zum Testen in meinem VS2015 community installiert nur bekomme ich leider nichts angezeigt.
    Das es Installiert ist sagt mir der Installer beim erneuten Versuch der Installation.

    Unter Extentions und Updates ist es aufgelistet und als Aktiv markiert.

  3. Hallo Ralph,

    Das ist wirklich eine geniale Idee, die ich gerne weiter spinnen würde, evtl. für andere Entwicklungshmgebungen. Ich denke, man sollte aber eine etwas komplexere Metrik verwenden, um die Qualität von Code zu messen. Evtl. bietet sich die sog. CRAP-Metrik an.

    Viele Grüße…

    • Wenn du Erfahrung in der Erweiterung anderer IDEs hast, bastle gern für die ein ähnliches Plugin. Wäre schön, wenn die Idee sich so verbreiten würde 🙂

      Von einer komplexeren Metrik werden wir einstweilen jedoch wohl Abstand nehmen. Alles mögliche in CRAP zu verrechnen gaukelt eine Gewissheit/Autorität vor, die schlicht nicht in den Metriken steckt. Und wie die zitierte Studie zeigt, haben komplizierte Metriken eben keine Vorhersagekraft, was den Veränderungsaufwand angeht – außer Anzahl Codezeilen.

      Davon abgesehen stehen manche Metriken auch nicht an der Stelle zur Verfügung, wo wir messen, z.B. Testabdeckung.

      Ob FFP überhaupt etwas bewirkt oder nicht, also einen Impuls zu anderen Verhalten auslöst, wird nicht von einem größeren Metrikaufwand abhängen.

      Dennoch Danke für deinen Vorschlag. Ich nehme ihn in unsere Feedbackliste auf.

  4. So nach den ersten 4 Stunden Refactoring ein paar Rückmeldungen.
    Es drängt einen wirklich dazu mehr zu extrahieren. Alleine durch bei Einfärbung.
    Anregen würde ich folgende Punkte:

    1. Es sollte bei der Ermittlung der Zeilen den Funktionsrumpf nicht mitzählen.
    2. Man sollte darüber nachdenken eine Option einzubinden die das Zählen von Leerzeilen und Kommentaren abschaltet. Wenn man jetzt In einer Firma Arbeitet die unnötige Kommentare  vorschreiben, könnte man so das Tool trotzdem nutzen um seine Funktionslänge kurz zu halten.

    Ich werde beide Punkte auch als Issues in github hinzufügen.
    Danke für die Idee und die Umsetzung an euch beide.

  5. Super!

    Ein kleiner Schritt in die Richtung sind ja Tools wie StyleCop, Linter, Resharper die einem mit Squigglies und kleinen Warndreiecken in die richtige Richtung drängen und dann mit einem grünen Häcken belohnen 🙂

    Aber ganze Code-Bereiche durch clevere Codeanalyse zu markieren und dann noch die Bearbeitung zu erschweren find ich grandios 🙂

    Bin gespannt wie sich das Tool entwickelt!

  6. PS: Als ich den Titel des Blogeintrags gelesen hab, dachte ich sofort an taktiles Feedback per Stromschlag durch die Tatstaur 🙂 Wann kommt dieses Features??

      • Sehr gut! Oder wie wäre es anderesrum mit einem Candy-Automat der einen fürs Refactoring belohnt? 🙂

        Habe letztens mit einem Kollegen über einen Gamification-Service nachgedacht den man überall andocken kann um Leaderboards und Achievements zu befüllen. Vielleicht wäre das ja auch was!

        • Das wäre spannend: ein per USB anschließbarer “Einmalspender”. Wenn der ein Signal bekommt, gibt er ein Goodie raus: Gummibär, Smartie, Zigarette… Was halt motivierend wirkt.

  7. Dem Wunsch Leerzeilen nicht mitzuzählen bzw. das konfigurierbar zu machen von Stephan Biegel schließe ich mich an.
    Das visuelle Feedback gefällt mir gut, das taktile Feedback sehe ich eher kritisch.
    Ich arbeite, so wie du, mit dem ReSharper, refakturiere oft direkt aus den Methoden heraus, dass würde dabei sehr stören und für mich kontraproduktiv sein.

  8. Pingback: Ralf Westphal | Force Feedback Programming auf der grünen Wiese

  9. Pingback: Introducing “Force Feedback Programming” | Tech News

  10. Bin gerade auf dein Tool gestossen. Find ich super!
    Gibt das auch für andere Visual Studio Version z.B. VS2012?

Comments are closed.