Änderbarkeit, Testbarkeit und Deploybarkeit: auf Veränderung auslegen

Drei Qualitäten rund um Veränderung

Der größte Teil der Kosten eines erfolgreichen Systems entsteht nach seinem ersten Release, wenn es wieder und wieder geändert wird. Drei verwandte Qualitäten beschreiben, wie gut eine Architektur das unterstützt. Bei Änderbarkeit geht es um Kosten und Risiko einer Änderung. Bei Testbarkeit geht es darum, wie leicht Sie durch Tests zeigen können, dass sich das System (oder ein Teil davon) wie beabsichtigt verhält, und wie bereitwillig sich Fehlerursachen zeigen. Bei Deploybarkeit geht es darum, wie schnell, sicher und vorhersehbar eine Änderung in Produktion gebracht und wieder zurückgenommen werden kann.

Sie hängen in einem Kreislauf zusammen. Eine Änderung ist nur dann günstig, wenn Sie sie an einer Stelle vornehmen können (Änderbarkeit), schnell wissen, dass Sie nichts kaputt gemacht haben (Testbarkeit), und sie ohne großes Zeremoniell ausliefern können (Deploybarkeit). Ein modulares System ohne schnelle Tests ändert sich trotzdem langsam, weil jede Änderung wochenlange manuelle Regressionstests braucht. Ein System mit guten Tests, aber einem vierteljährlichen Release-Fenster liefert trotzdem langsam Nutzen.

Änderbarkeit: vier Fragen zu jeder Änderung

Bass, Clements und Kazman legen nahe, dass Änderbarkeit bedeutungslos ist, solange Sie nicht sagen, was sich voraussichtlich ändern wird. Wer für jede denkbare Änderung plant, erhält ein überdimensioniertes System voller ungenutzter Erweiterungspunkte; wer für keine plant, erhält ein System, in dem jede Änderung eine Neuentwicklung ist. Vier Fragen schärfen die Anforderung.

Was kann sich ändern? Funktionen, Plattformen (eine neue Datenbankversion, der Umzug in eine andere Cloud), die Umgebung (eine neue Partner-API, neue Vorschriften), Qualitäten (die doppelte Last) oder die Kapazität. Wie wahrscheinlich ist die Änderung? Investieren Sie Designaufwand dort, wo Änderungen wahrscheinlich sind: Zahlungsanbieter, Steuerregeln und Benutzeroberflächen ändern sich oft; das Konzept einer Bestellung selten. Wer nimmt die Änderung vor, und wann? Ein Entwickler beim Programmieren, ein Release-Engineer beim Deployment, ein Administrator über die Konfiguration oder ein Endbenutzer über Einstellungen. Der Moment, in dem eine Entscheidung festgelegt wird, heißt ihr Bindungszeitpunkt. Was kostet die Änderung? Aufwand, Dauer und Geld, um sie umzusetzen, zu testen und zu deployen, dazu die Zahl der anderen betroffenen Elemente und das Risiko, Defekte einzuführen.

Die Antworten auf diese Fragen ergeben ein Szenario der Art, wie sie in Abschnitt 2.3 eingeführt wurde: Ein Entwickler fügt die Unterstützung für einen neuen Zahlungsanbieter hinzu, ändert außer der Konfiguration keine bestehenden Module, braucht dafür einschließlich Tests höchstens 3 Personentage, und die Fehler im Bezahlvorgang nehmen nicht zu.

Taktiken für Änderbarkeit

Die Taktiken in Software Architecture in Practice senken die Kosten von Änderungen, indem sie begrenzen, wie weit eine Änderung ausstrahlt. Sie beruhen auf zwei alten Ideen, die in Kapitel 3 ausführlich behandelt werden. Kohäsion misst, wie stark die Verantwortlichkeiten innerhalb eines Moduls zusammengehören; Kopplung misst, wie stark ein Modul von einem anderen abhängt. Eine wahrscheinliche Änderung sollte ein einziges kohäsives Modul betreffen, und dieses Modul sollte lose an den Rest gekoppelt sein.

Kohäsion erhöhen. Teilen Sie ein Modul auf, das zwei unzusammenhängende Aufgaben erledigt (ein CustomerService, der sowohl die Anmeldung als auch Treuepunkte verwaltet), und verschieben Sie Verantwortlichkeiten dorthin, wo sie hingehören, damit eine wahrscheinliche Änderung an einer Stelle landet.

Kopplung verringern. Kapseln: Verbergen Sie die Interna eines Moduls hinter einer expliziten Schnittstelle, nach David Parnas’ Prinzip des Information Hiding (1972), damit Aufrufer nicht von dem abhängen können, was sich ändern kann. Einen Vermittler nutzen: Setzen Sie etwas zwischen zwei Beteiligte, sodass keiner den anderen direkt kennt: einen Adapter, einen Message Broker, einen Publish-Subscribe-Kanal, ein Repository vor einer Datenbank oder ein API-Gateway. Abhängigkeiten beschränken: Legen Sie fest, welche Module welche aufrufen dürfen (Schichtregeln, ein Modul, das nur im eigenen Paket sichtbar ist), und setzen Sie das mit Werkzeugen durch. Gemeinsame Dienste abstrahieren: Stellen Sie gemeinsames Verhalten einmal hinter einer Schnittstelle bereit, statt es zu kopieren.

Bindung verschieben. Legen Sie eine Entscheidung so spät fest, wie es nützlich ist, damit die Änderung später und von jemandem weiter weg vom Code vorgenommen werden kann: Konfigurationsdateien, Umgebungsvariablen, beim Start erkannte Plug-ins, Service Discovery und Feature-Flags. Jeder spätere Bindungszeitpunkt bringt zusätzliche Mechanik mit sich (zu validierende Konfiguration, zu entfernende Flags, versionierte Plug-in-Schnittstellen); verschieben Sie daher nur Entscheidungen, die wirklich variieren.

Testbarkeit: Steuerbarkeit und Beobachtbarkeit

Eine Komponente ist testbar, wenn ein Test sie in einen bekannten Zustand versetzen, ihr gewählte Eingaben geben und sehen kann, was sie getan hat. Zwei Eigenschaften erfassen das. Steuerbarkeit ist die Fähigkeit, die Eingaben und den internen Zustand einer Komponente aus einem Test heraus festzulegen. Beobachtbarkeit (im Sinne des Testens) ist die Fähigkeit, ihre Ausgaben und den relevanten internen Zustand zu sehen. Code, der die Systemuhr direkt liest, einen echten Zahlungsdienst aufruft, Zufallszahlen wählt oder in eine gemeinsame Datenbank schreibt, ist schwer zu steuern; Code, der seine Ergebnisse in privatem Zustand oder nur im Logtext verbirgt, ist schwer zu beobachten.

Architekturtaktiken für Testbarkeit zielen daher darauf, Tests Kontrolle und Einblick zu geben und die Komplexität zu begrenzen. Isolieren Sie Abhängigkeiten hinter Schnittstellen und nutzen Sie dann Dependency Injection: Die Komponente erhält ihre Kollaborateure (eine Uhr, ein Payment-Gateway, ein Repository) von außen, statt sie selbst zu erzeugen, sodass ein Test einen Ersatz übergeben kann. Diese Ersatzobjekte sind Test Doubles, ein von Gerard Meszaros bekannt gemachter Begriff: Ein Stub liefert vorgefertigte Antworten, ein Fake ist eine funktionierende, leichtgewichtige Implementierung (ein In-Memory-Repository), ein Mock prüft, dass erwartete Aufrufe erfolgt sind, und ein Spy zeichnet Aufrufe für spätere Assertions auf. Stellen Sie Testschnittstellen bereit: Hooks, um Zustand zu setzen, Traffic aufzuzeichnen und wiederzugeben oder in einer Sandbox-Umgebung zu laufen. Begrenzen Sie Nichtdeterminismus: Vermeiden Sie versteckte Nebenläufigkeit und globalen Zustand, und machen Sie Zeit und Zufall injizierbar. Begrenzen Sie strukturelle Komplexität: Weniger Abhängigkeiten und keine Zyklen bedeuten kleinere Test-Setups.

Die Architektur prägt die Teststrategie auch auf höheren Ebenen. In einem System aus Services braucht jede Grenze Contract Tests, die prüfen, dass beide Seiten sich über die API einig sind, und einige End-to-End-Tests, die den echten Pfad durchlaufen. Ein Design mit klaren Grenzen lässt die meisten Tests schnell und isoliert laufen, während ein verworrenes Design langsame, fragile End-to-End-Tests für alles erzwingt.

class OrderService:
    def __init__(self, gateway, clock):
        self.gateway = gateway   # anything with charge(amount, card)
        self.clock = clock       # anything with now()

    def place(self, order):
        if self.clock.now().hour >= 23:
            return "kitchen closed"
        return self.gateway.charge(order.total, order.card)

# In a test: full control, no network, no waiting until 11 pm
class FakeClock:
    def __init__(self, t): self.t = t
    def now(self): return self.t

class FakeGateway:
    def __init__(self): self.calls = []
    def charge(self, amount, card):
        self.calls.append(amount)
        return "approved"

Deploybarkeit

Deploybarkeit misst, wie vorhersehbar und günstig eine Änderung vom Commit eines Entwicklers in die Produktion gelangt und wie schnell sie rückgängig gemacht werden kann. Zu einer vollwertigen Qualität wurde sie erst im letzten Jahrzehnt, als Continuous Delivery zeigte, dass Release-Häufigkeit und Stabilität keine Gegensätze sind. Die vierte Auflage von Software Architecture in Practice (2021) hat ihr ein Kapitel hinzugefügt.

Die zentrale Idee sind kleine Batches. Ein Release mit einer einzigen Änderung ist leicht zu testen, leicht zu durchschauen und leicht zurückzurollen; ein Release mit drei Monaten Arbeit enthält Hunderte zusammenwirkender Änderungen, sodass Ausfälle wahrscheinlich und schwer zu diagnostizieren sind. Kleine Batches erfordern Automatisierung: eine Deployment-Pipeline, die jede Änderung auf dieselbe Weise baut, testet und deployt, skriptgesteuerte Infrastruktur und keine manuellen Schritte, die jemand vergessen kann. Zu den Architekturtaktiken gehören unabhängig deploybare Einheiten (damit das Release eines Teams nicht auf das eines anderen wartet), abwärtskompatible Schnittstellen und Datenbankmigrationen, Mechanismen für Rollback und Roll-forward, schrittweise Rollouts (Canary Releases zunächst für einen kleinen Teil des Traffics, Blue-Green-Umschalten zwischen zwei Umgebungen) und Feature-Flags, die das Deployen von Code vom Freigeben einer Funktion für Benutzer trennen. Pipelines und Strategien werden in CI/CD-Pipelines und Deployment-Strategien behandelt.

Die Kosten, Deploybarkeit zu vernachlässigen, können gravierend sein. Im August 2012 deployte das Handelsunternehmen Knight Capital neuen Code manuell auf seine acht Order-Routing-Server, übersah aber einen. Ein wiederverwendetes Konfigurations-Flag aktivierte dann auf diesem Server veralteten Code, der den Markt mit Orders überflutete, in rund 45 Minuten etwa 4 Millionen Ausführungen erzeugte und das Unternehmen etwa 460 Millionen US-Dollar kostete. Ein automatisiertes, verifiziertes Deployment und das Entfernen toten Codes hätten es jeweils verhindert.

Auslieferung messen: die DORA-Metriken

Das DORA-Forschungsprogramm (DevOps Research and Assessment, beschrieben in Accelerate von Nicole Forsgren, Jez Humble und Gene Kim, 2018, und fortgeführt in Jahresberichten, die heute innerhalb von Google Cloud erstellt werden) fand heraus, dass eine kleine Zahl von Kennzahlen die Leistung der Softwareauslieferung vorhersagt und dass die Besten zugleich schnell und stabil sind. Das aktuelle Modell hat fünf DORA-Metriken für die Softwareauslieferung, gegliedert in Durchsatz und Instabilität. Ihre Namen haben sich entwickelt: Aus der alten Mean Time to Restore wurde 2023 die Wiederherstellungszeit nach fehlgeschlagenem Deployment, und die Deployment-Nacharbeitsrate kam 2024 hinzu.

Zwei Vorbehalte. Erstens beschreiben diese Metriken das Auslieferungssystem eines Teams, nicht Einzelpersonen; wer damit Menschen in eine Rangfolge bringt, lädt zum Schönen der Zahlen ein. Zweitens sind sie Ergebnisse. Die Architektur beeinflusst sie stark: Teams, die ihren Teil unabhängig deployen, isoliert testen und schnell zurückrollen können, schneiden besser ab; das ist ein Grund, warum die DORA-Forschung lose gekoppelte Architektur mit höherer Auslieferungsleistung verbindet.

Wartbarkeit in ISO/IEC 25010

ISO/IEC 25010:2023 fasst diese Anliegen unter dem Merkmal Wartbarkeit zusammen, mit fünf Teilmerkmalen: Modularität (das System besteht aus getrennten Komponenten, sodass eine Änderung an einer möglichst wenig Auswirkung auf andere hat), Wiederverwendbarkeit (ein Bestandteil kann in mehr als einem System oder beim Bau anderer Bestandteile verwendet werden), Analysierbarkeit (wie leicht sich die Auswirkung einer Änderung beurteilen, ein Mangel diagnostizieren oder die zu ändernden Teile finden lassen), Änderbarkeit (das System kann geändert werden, ohne Defekte einzuführen oder die Qualität zu mindern) und Testbarkeit (Testkriterien können festgelegt und Tests durchgeführt werden, um zu bestimmen, ob sie erfüllt sind). Deploybarkeit hat im Standard kein eigenes Teilmerkmal; Installierbarkeit und Austauschbarkeit gehören zur Flexibilität. Das Modell ist eine Checkliste, wie Abschnitt 2.2 erklärt; erst Szenarien machen jeden Punkt konkret.