Construct to deconstruct

Bild: Javier Alvarez / Picryl - Public Domain

In der agilen Softwareentwicklung sollte man sich stets eines Grundsatzes bewusst sein: alle Methoden, Frameworks, Meetings, Rollen, Werte und Prinzipien sind schön und gut, wenn die entstehende Software aber nicht schnell und mit vertretbarem Aufwand anpassbar ist, ist all das nur von bescchränktem Wert. Auch Entwicklungs-Praktiken und Architektur-Muster sind daher von Bedeutung, unter anderem eines, der leider ralativ unbekannt ist: Construct to deconstruct.

Die Grundidee dahinter ist einfach: zum agilen Entwicklen von Software gehört auch, dass vergangene Erweiterungen oder Modifikationen wieder rückgängig gemacht werden, sei es, weil es sich bei ihnen um Übergangslösungen oder MVPs gehandelt hat, oder seit es weil sich herausgestellt hat, dass bei den Anwendern keine Nutzungs- oder Bezahlbereitschaft besteht. In diesen und in anderen Fällen macht ein rückgängig Machen Sinn, um Umfang und Komplexität der Codebase zu reduzieren.

Dort wo das nicht schnell und einfach möglich ist, können verschiedene negative Auswirkungen auftreten - bestenfalls ist die Wiederherstellung eines früheren Zustandes einfach nur aufwändig und beansprucht Zeit und Ressourcen, schlimmstenfalls ist es nicht möglich und eine mit dem früheren Zustand vergleichbare Ersatzlösung muss gebaut werden, was nicht nur aufwändig ist, sondern ggf. auf Kosten von Konsistenz, Updatefähigkeit (bei Standardsoftware) oder Ähnlichem geht.

In der Umsetzung besteht die häufigste und offensichtlichste Form einer Construction for Deconstruction aus einer modularen Architektur der jeweiligen Software. Diese ist gegeben, wenn die Anwendung in selbstständige, voneinander unabhängige Einheiten gegliedert ist, die jeweils eine bestimmte (bestenfalls fachliche) Funktion erfüllen, mit anderen Einheiten nur über fest definierte Schnittstellen verbunden sind und einzeln angepasst werden können, ohne die jeweils anderen auch verändern zu müssen.

Ebenfalls offensichtlich ist, dass der vorherige Zustand bekannt bleiben muss, um wiederhergestellt werden zu können. Das kann ganz banal durch ein Abspeichern eines bestimmten Entwicklungsstandes des Codes stattfinden (und nicht nur der jeweils letzten Versionen), aber auch durch ein Sichern des entsprechenden Standes der dazugehörigen Dokumentation, idealerweise in einer Form, die nicht nur den Zustand beschreibt, sondern auch auch die Entscheidungen die ihm zugrundeliegen.

Etwas weniger offensichtlich aber nicht weniger bedeutsam ist, dass auch der zwischenzeitlich angepasste und jetzt wieder zu entfernende, bzw. auf den früheren Zustand zurückzusetzende Code verständlich und gut dokumentiert ist. Nur wenn sicher ist was er tut und welche Abhängigkeiten von ihm ausgehen kann er entfernt, bzw. zurückgesetzt werden, ohne dass es dabei zu überraschenden Seitenauswirkungen kommt, die wiederum ungeplante Verzögerungen und Aufwände mit sich bringen.

Und natürlich sind auch hier Testabsicherung / Testabdeckung und Monitoring von Bedeutung. Sowohl bei der Validierung ob der "neue alte Zustand" funktionsfähig ist, als auch bei der Sicherstellung, dass die Entfernung des "alten neuen Zustandes" keine unerwarteten Probleme mit sich bringt sind sie für eine schnelle und sichere Umsetzung unverzichtbar (bzw. wenn sie nicht gegeben sind ist mit hohen Aufwänden und verspätet erkannten Überraschungen zu rechnen).

Zuletzt noch eine nicht-technische Anmerkung: dass der Construct to deconstruct-Grundsatz nur verhältnismässig selten befolgt wird hat unter anderem einen sehr menschlichen Grund: es erscheint (bewusst und unterbewusst) naheliegender Veränderungen herbeizuführen, indem man etwas Bestehendem etwas Neues hinzufügt, und weniger naheliegend, dafür etwas Bestehendes zu entfernen. Mehr dazu hier, im Nature-Magazin.