In diesem Bereich

Links

Ein vorhandenes System zur Scatterware umwandeln

Jedes große Softwaresystem läuft Gefahr, im Laufe der Weiterentwicklung immer mehr Schnittstellen zwischen den Modulen auszubilden. Die enge Vernetzung ist einer der Hauptgründe dafür, dass nach Ausspielungen oder besonders nach Hotfixes unerwartete Fehlfunktionen auftreten, die sich in der Testumgebung nicht nachstellen lassen.

Ein Modul, das mit einem dutzend anderer Module eng verzahnt ist und das womöglich noch zwei vergessene, undokumentierte, aber wesentliche Seiteneffekte erzeugt, kann nicht neu geschrieben werden. In Scatterware nennt man solch ein Modul Blackbox. Bei diesem hypothetischen Softwaresystem, das eine oder mehrere, so definierte Blackboxen enthält, haben wir es also sicher nicht mit Scatterware zu tun und können es auch nicht "einfach in Scatterware verwandeln".

Efeu an schwarzen Kisten

Man darf sich nichts vormachen: ein solches System muss neu geschrieben werden. Zumindest müssen die Blackboxen neu geschrieben werden, die nicht mehr ohne Gefahr für die Funktionsfähigkeit des Gesamtsystems weiterentwickelt werden können. Die gute Nachricht: mit Scatterware gibt es eine Möglichkeit, ein so fragiles System zu stabilisieren.

Der Ansatz ist, die Blackboxen zu umranken. Es werden Wrapper geschrieben, die die Blackboxen gegenüber dem restlichen System isolieren. Damit bleiben die Blackboxen in Funktion und ihr unmittelbares Umfeld ändert sich nicht mehr. Neue Funktionalität wird in anderen Scatterware-Kapseln an den Blackboxen vorbei entwickelt. Dadurch wird die Funktion der Blackbox nach und nach abgelöst und schließlich ganz obsolet, sodass die Blackbox aus dem System entfernt werden kann.

Falls die Gefahr besteht, dass andere Blackboxen des Systems noch auf undokumentierte Seiteneffekte oder Nebenfunktionen des ausgephasten Moduls aufbauen, kann die umrankte Blackbox schlimmstenfalls als eine Art Blinddarm weiter enthalten bleiben. Da sie nicht mehr regulär verwendet wird, sollte die Blackbox im Fehlerfall auch keinen Schaden mehr anrichten.

Twyniwyd

Eines dieser computertypischen, schwer lesbaren Akronyme: es steht für Take What You Need, Ignore What You Don't. Jeder Browser sollte eigentlich so funktionieren: wenn er von einer Webseite einen HTML-Code geliefert bekommt, den er nicht versteht, dann soll er nicht mit wüsten Fehlermeldungen reagieren. Er soll aus den Informationen, die ihm im HTML zur Verfügung gestellt werden, alles herauslesen, was er zur Darstellung der Webseite benötigt (take what you need) und soll alles, was er nicht kennt, ohne Störungen und ohne den Anwender zu verwirren übergehen (ignore what you don't [need]).

Das ist ein wichtiges Theorem der Scatterware. Um zu erreichen, was Scatterware zum Ziel hat - jedes Modul jederzeit in jedweder Sprache neu schreiben zu können - müssen alle Schnittstellen diesem Leitsatz folgen. Wenn man neue Funktionalität implementieren möchte, dann müssen meist mehrere Kapseln angepasst werden. Scatterware legt zudem nahe, eine Kapsel gleich neu zu schreiben, wenn die Anpassung so umfangreich ist, dass man viel Zeit investieren müsste, sich in den vorhanden Code einzuarbeiten. Oder wenn die neuen Features mit einer anderen Programmiersprache besser umsetzbar sind.

Neu und Alt verträgt sich

Bei einer herkömmlichen Software-Architektur wird man zu Beginn einer Neuentwicklung einen Branch in der Versionsverwaltung einrichten und alle beteiligten Module so umschreiben, dass die neue Funktionalität hergestellt wird. Die meisten der neuen Module funktionieren nicht zusammen mit den meisten der alten Module. Abwärtskompatibilität ist überflüssig, sie zu erhalten gilt als ineffiziente Redundanz.

In konsequenter Scatterware kann man dagegen jede einzelne Kapsel erweitern und sofort in das Livesystem integrieren. Die erste Kapsel, die man auf dem Weg zum neuen Feature ersetzt, kann also mehr als ihre Vorgängerin. Die Informationen, die sie an die nächstfolgende Kapsel ihres Fließbands übergibt, sind vermutlich in irgendeiner Form erweitert.

Twyniwyd besagt, dass die noch nicht erweiterte Kapsel sich daran nicht stören wird. In herkömmlicher Teamarbeit zur Softwareherstellung gilt es als gute Praxis, jede Fehlersituation sofort zu protokollieren oder gleich zu einer Fehlermeldung zu eskalieren. Scatterware dagegen erlangt viel seiner Robustheit dadurch, dass nur eine Verletzung der Muss-Bedingungen zu einer Exception führt. Dadurch kann jede neue Kapsel mit einem Minimum an Tests und geringstmöglichem Risiko in die Liveumgebung integriert werden.

Bei einer herkömmlichen Ausspielung dutzender oder hunderter neuer und geänderter Module gleichzeitig, kann dagegen auch mit sehr sorgfältiger und daher zeitaufwändiger Qualitätssicherung das Risiko von unerwünschten Nebenwirkungen nie wirklich ganz eliminiert werden. Da erfahrungsgemäß solche Fehlfunktionen erst Stunden oder Tage nach dem Livegang auffallen, ist ein Roll-Back bis dahin meist nicht mehr möglich. Die Folge sind hektische Symptombekämpfungsmaßnahmen, die erheblich Zeit fressen und schwer zu koordinieren sind.

Am Ende hat man mit relativ geringem Invest in Twyniwyd eine Menge Arbeit im Bereich Koordination, QS, Ausspielung, Bereitschaftsdienst und Dokumentation eingespart.

weiter mit einer Scatterware Fallstudie