Kurzdefinition

Eigenschaft eines Systems, dessen Verträge zwischen den APIs, dessen Fachregeln und dessen Tests für das erwartete Verhalten so gut auffindbar und so klar voneinander getrennt sind, dass ein Team es anderswo, in einer anderen Technologie, neu bauen könnte.

Ausführliche Definition

Außerhalb dieses Blogs ist das Wort in mehreren Bedeutungen unterwegs. Im Betrieb bezeichnet es die Fähigkeit, eine Umgebung aus ihren Quellen und ihrer Konfiguration identisch neu zu erzeugen. In der Archivierung und in der Data Science bezeichnet es die Möglichkeit, ein Datum oder ein Ergebnis aus dem Aufbewahrten wiederzugewinnen.

In den Artikeln dieses Blogs bezeichnet der Begriff eine Eigenschaft des Verständnisses, nicht der Werkzeuge: Ein System ist rekonstruierbar, wenn man es neu bauen könnte, und das setzt voraus, dass man weiß, wo die Grenzen liegen — wo der Vertrag einer Schnittstelle verläuft, wo die Fachregeln leben, welche Tests das erwartete Verhalten beschreiben statt der aktuellen Implementierung. Der Neuaufbau muss nicht tatsächlich stattfinden: Er dient als Kontrollfrage, die an die Stelle von „Funktioniert es?“ tritt.

Normativer Sinn und Gebrauch in der Praxis gehen in einem Punkt auseinander. Die Norm verlangte einen identischen Neuaufbau, bis ins Detail der Implementierung. In der Praxis lautet die Frage schwächer und nützlicher: Könnte man dasselbe Verhalten mit anderen Mitteln erreichen, ausgehend von dem, was das System selbst über sich sagt?

Gebrauch im Feld

Der Begriff dient als Qualitätskriterium für eine mit einem Assistenten entwickelte Software, dort, wo die Auslieferungsgeschwindigkeit nichts mehr darüber sagt, ob man das System im Griff hat. Er kommt auch bei Architekturentscheidungen ins Spiel — Verträge zwischen den APIs durchsetzen, die Testpyramide vor der Entwicklung schreiben, sich weigern, die Fachlogik über die Endpunkte zu verstreuen — und in Reviews am Ende eines Vorhabens, als Frage, die die funktionale Vorführung ersetzt.

Synonyme und Varianten

„Könnte ich es neu aufbauen?“ — die Frageform ist der übliche Gebrauch des Begriffs. Belegte Varianten: „das System im Griff haben“, „Ankerpunkte“, „Trennlinien“.

Nicht zu verwechseln mit

• Verständnisschuld — Passivposten, den ein Team bei einem System anhäuft, das es nicht erklären kann; die Rekonstruierbarkeit ist der entsprechende Aktivposten, und bei einem System, das ein Team noch nicht angefasst hat, kann es weder das eine noch das andere haben.
• Reproduzierbarkeit eines Builds — Eigenschaft einer Herstellungskette, die aus denselben Eingaben dasselbe Artefakt erzeugt; sie betrifft die Werkzeuge und lässt sich automatisch prüfen, ohne dass irgendein Mensch verstanden hätte, was das System tut.
• Portabilität — Fähigkeit einer Software, in einer anderen Umgebung zu laufen, ohne neu gebaut zu werden; sie erspart den Neuaufbau, statt ihn möglich zu machen.
• Architekturdokumentation — Beschreibung des Systems in seinem gegenwärtigen Zustand; sie kann vollständig sein und ein System hinterlassen, das man nicht neu bauen könnte, und sie kann bei einem System fehlen, dessen Tests das Verhalten hinreichend festhalten.
• Technische Schulden — Entwurfsschwäche, deren Behebung beschlossen und budgetiert wurde; ein System kann hoch verschuldet und trotzdem vollständig rekonstruierbar sein, denn das eine bewertet den Entwurf, das andere das, was man über das System sagen kann.

Beispiele

„Wenn ich diese Anwendung morgen in eine andere Technologie überführen muss, weiß ich, wo die Verträge liegen, wo die Fachregeln liegen, wo die Tests liegen, die das erwartete Verhalten beschreiben.“ — der Referenzgebrauch, bezogen auf eine mit einem Assistenten entwickelte Anwendung.

Bei einem Projekt, das kein vollständiges DDD-Vorgehen rechtfertigt, darauf zu verzichten und sich zugleich zu weigern, die Fachlogik über die Endpunkte zu verstreuen, ist eine Abwägung zugunsten der Rekonstruierbarkeit: Man sucht nicht die Reinheit des Modells, sondern erkennbare Trennlinien.

Mehrdeutigkeiten / Debatten

Der angestrebte Umfang ist nicht festgelegt: das Verhalten neu aufbauen, die Architektur neu aufbauen oder den Code neu aufbauen. Hier gilt die erste Bedeutung.

Noch weniger festgelegt ist die Überprüfung. Niemand baut neu, nur um zu prüfen, ob er es gekonnt hätte; das Kriterium bleibt also eine Frage der Selbstprüfung — und damit der Nachsicht dessen ausgeliefert, der sie beantwortet.