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.
3 Kommentare:
Das man für das Einbauen neuer Anforderungen unbedingt refaktorisieren sollte (oft vorher und hinterher), das erlebe ich beim täglichen Entwickeln genauso.
Was ich allerdings seltsam finde, ist der Vergleich, das hier "Refaktoriseren" mit "Unordnung schaffen" gleichgesetzt wird. Refaktorisieren ist für mich immer ein weg, den Code zu verbessern, also mehr Ordnung zu schaffen. Auch und gerade dann, wenn man das vorher macht, um neue Anforderungen einzubauen. Zum Beispiel, um die Anzahl der Eingriffspunkte in den Code, die man für eine neue Anforderung brauchen wird, im Vorfeld zu verringern. Oder die Verständlichkeit eines Codeblocks erhöht, um die Wahrscheinlichkeit zu erhöhen, bei der anstehenden Erweiterung nichts falsch zu machen.
Gutes Refaktorisieren geht auch in möglichst kleinen Schritten vor - anstatt einer "grossen" Umbauaktion möglichst viele kleine, die in Summe das Gleiche bewirken. Zwischendurch wird immer wieder ein "ordentlicher Zustand" hergestellt. Daher kann ich auch nicht nachvollziehen, was hier mit "wir lassen noch zuwenig Unordnung im Code zu" gemeint ist. Aus meiner Sicht fördert gerade Ordnung und Struktur die Evolvierbarkeit von Code - Unordnung entsteht da wirklich nur kurzzeitig - zwischen Anfang und Ende eines möglichst kleinen Refaktorisierungsschrittes zum Beispiel, oder währen des Einbaus eines neuen Features, bevor wir durch Refaktorisieren wieder aufgeräunmt haben.
Aber ich habe doch gar nicht gesagt, dass Refaktorisieren "Unordnung schaffen" bedeutet. Im Gegenteil!
Ich will nur hervorheben, dass wir nicht mal den Hauch eines Ideals haben sollten, dass Veränderung ohne Unordnung abgehen könnte und insofern kein Aufräumen (Refaktorisieren) nötig sein könnte.
In jedem Fall muss nach der Veränderung, also nach Herstellung der Erfüllung einer Anforderung, refaktorisiert werden. Muss! Es geht kein Weg dran vorbei! Denn die Erfüllung der Anforderung erzeugt immer Unordnung/Dreck.
Aber - und das war für mich eine Erkenntnis - wie müssen womöglich sogar Unordnung herstellen, bevor wir das tun können, was wir eigentlich tun wollen. Vielleicht habe ich das noch nicht genug beton.
Wir müssen womöglich De-Refaktorisieren. So wie im Wohnzimmer die Ordnung aus Tisch und Bank dekonstruiert werden musste, damit die Bildleiste angebracht werden konnte.
Eine solche De-Refaktorisierung sehen wir als noch nicht nötig bzw. hoffähig an. Wir glauben, ohne auskommen zu können.
Klar, manchmal ist das so. Für einen Nagel an der Wand wird keine Ordnung im Wohnzimmer dekonstruiert.
Aber wenn die Anforderung größer ist, dann ist eine Dekonstruktion der existierenden Ordnung völlig ok.
Und genau das müssen wir als Möglichkeit in Betracht ziehen bei Software, finde ich. Der bisherige Clean Code Gedanke scheint mir da jedoch widerspenstig. Der hat ein anderes Ideal.
Unordnung ist das halbe Leben ;)
Kommentar veröffentlichen