Neulich habe ich mit meiner Freundin geheimwerkert. Sie wollte ihr Wohnzimmer mit einigen Fotos in selbstgebastelten Bilderrahmen anreichern. Holzprofile zuschneiden und zusammensetzen zu Rahmen, war eine Sache. Eine andere, die Bilderleiste im Wohnzimmer anzubringen, an der die Rahmen aufgehängt werden können. (Eine Bilderleiste statt Nägeln in der Wand für jeden Rahmen sollte es sein, damit die Rahmen flexibler gehängt werden können.)
Bei der Montage der Bilderleiste habe ich dann eine Erkenntnis gehabt:
Unordnung ist bei Veränderungen nicht zu vermeiden.
Wer Rahmen bastelt, eine Bilderleiste anbringt, einen Weihnachtsbaum herrichtet, ja, sogar wer aufräumt, erzeugt Unordnung. Das ist nicht zu vermeiden. Auch wenn am Ende die Entropie niedriger sein soll, wird sie zunächst erhöht.
Hier das Wohnzimmer während der Arbeit an den Bilderleisten in seiner ganzen Unordnungspracht:
Die Sitzbank ist bis aufs Holz abgeräumt, der Wohnzimmertisch ein Werkzeuglager, der Sessel beiseitegeschoben und mit Krimskrams beladen, Staubsauger und Bohrmaschine lungern in der Gegend herum… Nein, das ist nicht die übliche niedrig-entropische Gemütlichkeit.
Am Ende jedoch, wenn die Veränderungen an der Wand abgeschlossen sind, kommt alles wieder an seinen Platz. Dann herrscht wieder Ordnung. (Dass die Bilderrahmen in unterschiedlicher Höhe und Orientierung hängen, gehört zu dieser Ordnung ;-)
Ohne die zwischenzeitliche Unordnung wäre die Veränderung nicht umsetzbar gewesen. Oder der Aufwand wäre viel, viel höher ausgefallen. Ich denke, da werden Sie mir zustimmen.
Wer einen ordentlichen Zustand in einen anderen, “erweiterten” ordentlichen Zustand überführen will, der erzeugt auf dem Weg dahin Unordnung.
Vorher hat das Wohnzimmer gewisse funktionale und nicht-funktionale Anforderungen erfüllt. Jetzt erfüllt es neue nicht-funktionale Anforderungen. Vorher war es ordentlich, jetzt ist es wieder ordentlich. Alles wunderbar.
Nur bei Quellcode oder anderen Artefakten der Softwareentwicklung soll das anders sein?
Merkwürdig, oder?
Was Unordnung bei Quellcode genau ist, sei mal dahingestellt. Aber dass es Unordnung geben kann, nein, geben muss, sollte außer Zweifel stehen. Auch für einen Laien.
Und genauso sollte außer Zweifel stehen, dass eine Veränderung an Quellcode zu Unordnung führen muss. Zwangsläufig. Immer.
Zumindest halte ich das für absolut einsichtig unter der Voraussetzung, dass Quellcode nach erfolgreichem Abschluss von Veränderungen, ordentlich zurückgelassen wird. Es geht also so mit dem Quellcode:
Anforderungen A+B werden erfüllt –> Veränderungen für C anbringen –> Anforderungen A+B+C werden erfüllt
In Bezug auf die Ordnung sieht das so aus:
Ordnung –> Unordnung –> Ordnung
Wer hat also je überhaupt annehmen können, dass es ohne Clean Code, ohne Refactoring geht? Das war und ist widersinnig. So funktioniert die Veränderung von etwas Ordentlichem nicht.
Wenn professionelle Arbeit in etwas Ordentlichem resultiert – vom Klempner über den Arzt bis zum Softwareentwickler –, dann darf und muss zwischendurch im Verlauf der Arbeit Unordnung entstehen. Und die wird am Ende aufgeräumt. So ist das immer.
Und jetzt nochmal die Frage: Wer glaubt, dass bei der Veränderung von Quellcode zur Erfüllung neuer Anforderungen (oder auch zum Bug Fixing) ohne Unordnung abgehen kann?
Aus meiner Sicht sind das viele Entwickler. Und es sind noch mehr nicht-Entwickler. Der Glaube ist so weit verbreitet, dass Refactoring immer noch einer besonderen Begründung bedarf. Wie oft habe ich gehört, “Für Clean Code haben wir keine Zeit. Wenn uns jemand dabei sieht, wie wir ein Refactoring durchführen, dann haben wir Erklärungsnot.”
Aber das ist Quatsch. Nach dem Bilderleisteneinsatz im Wohnzimmer ist mir das nochmal ganz deutlich geworden.
- Professionelle Arbeit hinterlässt ein System in einem ordentlichen Zustand.
- Veränderungen an einem ordentlichen System führen zwangsläufig zu Unordnung. Die sollte man gar nicht erst vermeiden wollen.
- Um nach Veränderungen wieder ein ordentliches System zu haben, muss aufgeräumt werden.
Unordnung herstellen, um effizient Veränderungen vornehmen zu können – hier: Tisch verrücken, Polster von der Sitzbank nehmen, Werkzeuge bereitlegen – und Ordnung nach Abschluss der Veränderungen wieder herstellen, sind die Klammern professioneller Arbeit.
Ich glaube sogar, dass wir während der Veränderung unseres Quellcodes noch zuwenig Unordnung zulassen. Wir meinen, es ginge ohne. Wir versuchen, mit Überziehern an den Schuhen auf Sitzbankpolstern vorsichtig herumzutreten. Gebohrt wird nicht, denn das macht ja Dreck. Besser nur vorsichtig kleben. Und langsam arbeiten, damit nichts zerbrechliches umgeworfen wird.
Wir versuchen also, Strukturen zu verändern, ohne sie temporär zu “verstören”. Das ist gut gemeint – aber an der Realität effizienter Veränderungsarbeit vorbei, glaube ich.
Nicht nur ist es ganz normal, nach Veränderungsarbeit Ordnung herzustellen; Stichwort Refactoring. Es ist auch ganz normal, vor (!) Veränderungsarbeit Unordnung herzustellen, wenn das einer effizienteren Veränderung dient.
Also, haben Sie kein schlechtes Gewissen, wenn Sie für eine neue Anforderung mal Unordnung erzeugen. Haben Sie auch kein schlechtes Gewissen, hinterher immer aufzuräumen. Das ist normal, unvermeidbar, professionell. Widersetzen Sie sich Anweisungen, die das Gegenteil verlangen. Zur professionellen Arbeit gehört Ordnung im Ergebnis – genauso wie zwischenzeitliche Unordnung.
