Anforderungen, Versionskontrolle, Tests, Auslieferung und der Weg einer Anfrage

Von der Idee zur Anforderung

Software beginnt mit einem Bedürfnis: Ein Restaurant möchte Bestellungen online annehmen, ein Krankenhaus möchte, dass Patienten ihre Termine selbst buchen. Dieses Bedürfnis in etwas zu übersetzen, das ein Team bauen kann, ist die Arbeit mit Anforderungen. Manche Anforderungen beschreiben, was das System tun muss („ein Kunde kann per Karte bezahlen“); andere beschreiben, wie gut es das tun muss („der Bezahlvorgang ist für 95 % der Kunden innerhalb von zwei Sekunden abgeschlossen“). Kapitel 2 zeigt, dass die zweite Art, die Qualitätsmerkmale, die meisten Architekturentscheidungen treibt.

Viele Teams halten funktionale Bedürfnisse als User Stories fest: kurze Beschreibungen aus Sicht der Nutzer. Kent Beck führte sie Ende der 1990er-Jahre im Extreme Programming ein, und ein Team beim Londoner Unternehmen Connextra entwarf 2001 die Vorlage, die heute die meisten verwenden:

As a hungry customer,
I want to reorder a meal I have ordered before,
so that I can eat sooner without searching the menu again.

Acceptance criteria
- My last 10 orders appear on the home screen.
- Tapping "Reorder" fills the basket with the same items.
- Items that are no longer available are flagged, not silently dropped.

Eine Story ist bewusst klein und unvollständig. Ron Jeffries beschrieb sie als Karte, Gespräch und Bestätigung (Card, Conversation, Confirmation): Die Karte ist eine Erinnerung, die Details werden im Gespräch zwischen denen geklärt, die das Feature wollen, und denen, die es bauen, und die Akzeptanzkriterien bestätigen, wann es fertig ist. Fachleute sind uneins darüber, wie viel vorab aufgeschrieben werden sollte. Teams in regulierten Branchen wie Medizinprodukten und Luftfahrt müssen formale, nachverfolgbare Anforderungen führen; Produktteams bevorzugen oft schlankere Stories, die kurz vor Arbeitsbeginn verfeinert werden. Beides ist in seinem Kontext legitim.

Versionskontrolle mit Git

Quellcode ist das wertvollste gemeinsame Dokument des Teams, und viele Menschen ändern ihn täglich. Versionskontrolle zeichnet jede Änderung auf, wer sie vorgenommen hat und warum, lässt Menschen parallel arbeiten, ohne sich gegenseitig zu überschreiben, und erlaubt es, jeden früheren Stand wiederherzustellen. Fast jedes Team nutzt heute Git, das Linus Torvalds 2005 für die Entwicklung des Linux-Kernels geschaffen hat, meist zusammen mit einem Hosting-Dienst wie GitHub, GitLab oder Bitbucket.

Wenige Begriffe decken den größten Teil des Alltags ab. Ein Commit ist ein gespeicherter Schnappschuss einer Reihe von Änderungen mit einer erklärenden Nachricht („Add tip button to checkout“). Ein Branch ist ein eigener Arbeitsstrang: Eine Entwicklerin legt einen Branch von main an, macht dort Commits, ohne jemanden zu stören, und mergt den Branch nach Abschluss zurück, wobei die beiden Historien zusammengeführt werden. Haben zwei Personen dieselben Zeilen geändert, meldet Git einen Merge-Konflikt, den ein Mensch auflösen muss.

Auf Hosting-Diensten läuft das Mergen meist über einen Pull Request (bei GitLab Merge Request genannt): eine Webseite mit der vorgeschlagenen Änderung, auf der automatische Prüfungen laufen und Kolleginnen und Kollegen ein Code-Review durchführen, also die Änderung lesen, Fragen stellen und Verbesserungen vorschlagen, bevor sie sie freigeben. Reviews finden Fehler, aber ihr größerer Nutzen ist, Wissen zu verbreiten (mindestens zwei Personen verstehen jede Änderung) und das Design konsistent zu halten. Architekten beteiligen sich oft an Reviews von Änderungen, die Struktur oder Schnittstellen betreffen.

git switch -c feature/tip-button     # create a branch and move onto it
# ... edit files ...
git add checkout.py test_checkout.py
git commit -m "Add tip button to checkout"
git push -u origin feature/tip-button  # upload; then open a pull request
# after review and green checks, the branch is merged into main

Beim Branching gehen Teams unterschiedlich vor. Manche führen langlebige Branches pro Feature oder Release; andere praktizieren Trunk-Based Development, mergen kleine Änderungen mindestens täglich in main und verbergen unfertige Features hinter Schaltern, sogenannten Feature-Flags. Die Forschung des DORA-Programms bringt kurzlebige Branches mit besserer Delivery-Performance in Verbindung, aber die richtige Wahl hängt auch davon ab, wie ein Team Releases ausliefert.

Testen: die Pyramide

Jede Änderung riskiert, etwas kaputt zu machen, das vorher funktioniert hat; das nennt man eine Regression. Automatisierte Tests sind Programme, die andere Programme prüfen, daher lassen sie sich bei jeder Änderung in Minuten ausführen statt in Tagen durch Menschen. Es gibt sie in Schichten. Ein Unit-Test prüft ein kleines Stück, etwa eine Funktion, isoliert und läuft in Millisekunden. Ein Integrationstest prüft, ob Teile zusammenarbeiten: der Bestellcode mit einer echten Datenbank oder der Shop mit der Testumgebung eines Zahlungsanbieters. Ein End-to-End-Test steuert das ganze System so, wie es ein Nutzer täte, zum Beispiel indem er sich in der App von der Speisekarte bis zur Bestellbestätigung durchtippt.

Mike Cohns Testpyramide, veröffentlicht 2009 in seinem Buch Succeeding with Agile, schlägt die Proportionen vor: viele Unit-Tests, weniger Integrationstests und wenige End-to-End-Tests. Die höheren Schichten sind realistischer, aber langsamer, teurer in der Wartung und anfälliger für Flaky-Fehlschläge, die aus Gründen kommen und gehen, die nichts mit der Änderung zu tun haben. Manche Fachleute plädieren für eine andere Form, etwa mehr Integrationstests bei Systemen, die vor allem Bindeglied zwischen Services sind; einig sind sich alle im Grundsatz, die meisten Probleme mit schnellen, zuverlässigen, fokussierten Tests abzufangen.

def delivery_fee(basket_total, distance_km):
    if basket_total >= 25:
        return 0.0                      # free delivery on larger orders
    return round(1.50 + 0.40 * distance_km, 2)

def test_free_delivery_over_threshold():
    assert delivery_fee(30.00, 5) == 0.0

def test_fee_grows_with_distance():
    assert delivery_fee(10.00, 5) == 3.50

Umgebungen: von der Entwicklung bis zur Produktion

Code durchläuft auf seinem Weg zu den Kunden mehrere Umgebungen, jede eine eigene Kopie des Systems mit eigenen Servern, Daten und Einstellungen. Ziel ist es, Probleme dort zu finden, wo sie billig und harmlos sind, bevor sie die Produktion erreichen, die Live-Umgebung, auf die echte Nutzer angewiesen sind.

Je stärker Umgebungen von der Produktion abweichen, desto mehr Probleme rutschen durch: Eine Testdatenbank mit hundert Zeilen verrät nicht den fehlenden Index, durch den eine Abfrage bei zehn Millionen Zeilen vierzig Sekunden dauert. Umgebungen ähnlich zu halten ist leichter, wenn sie aus denselben Container-Images und derselben per Skript erzeugten Konfiguration gebaut werden, ein Thema von Infrastructure as Code.

Continuous Integration, Delivery und Deployment

Continuous Integration (CI) ist die Praxis, die Arbeit aller häufig, mindestens täglich, in die gemeinsame Hauptlinie zu mergen, wobei ein automatischer Build- und Testlauf jede Änderung prüft. Sie ging in den 1990er-Jahren aus dem Extreme Programming hervor. Ihr Sinn ist, dass Integrationsprobleme innerhalb von Minuten gefunden werden, solange die Änderung der Autorin oder dem Autor noch frisch im Kopf ist, statt Wochen später in einer mühsamen „Integrationsphase“. Ein Team, das CI praktiziert, behandelt einen fehlgeschlagenen Build als Notfall: Ihn zu reparieren geht jeder neuen Arbeit vor.

Continuous Delivery (CD) erweitert CI so, dass die Software jederzeit releasefähig ist: Jede Änderung, die die Pipeline durchläuft, könnte auf Knopfdruck in Produktion gehen, und ein Release wird zu einer routinemäßigen Geschäftsentscheidung statt zu einem riskanten Ereignis. Den Ansatz beschrieben Jez Humble und David Farley 2010 in ihrem Buch Continuous Delivery. Continuous Deployment geht einen Schritt weiter und gibt jede erfolgreiche Änderung automatisch frei, ohne menschliche Freigabe; Teams, die das tun, deployen unter Umständen viele Male am Tag.

Die Automatisierung, die eine Änderung vom Commit bis in die Produktion trägt, ist eine Pipeline. Weil jeder Schritt automatisiert und jedes Mal identisch ist, hängen Releases nicht mehr davon ab, dass sich eine Person um Mitternacht an eine Checkliste erinnert.

Arbeitsweisen: Wasserfall, Scrum und Kanban

Teams entscheiden auch, wie sie die Arbeit selbst organisieren. Bei einem sequenziellen Vorgehen, oft Wasserfall genannt, durchläuft das Projekt Phasen der Reihe nach: Anforderungen, Entwurf, Implementierung, Test, Deployment. Jede Phase endet, bevor die nächste beginnt. Der Name wird meist auf Winston Royces Aufsatz von 1970 zurückgeführt, obwohl Royce das Wort nicht verwendete und sogar davor warnte, dass ein einziger Durchlauf durch die Phasen riskant sei. Sequenzielle Pläne passen nach wie vor zu Arbeit, bei der die Anforderungen feststehen und Änderungen sehr teuer sind, etwa bei manchen regulierten oder hardwareabhängigen Projekten. Ihre Schwäche für die meiste Software ist, dass Nutzer bis spät nichts sehen, sodass Missverständnisse dann auftauchen, wenn sie am teuersten zu beheben sind.

Agile Ansätze, benannt im Agilen Manifest von 2001, liefern funktionierende Software in kurzen Zyklen und passen Pläne an, während sie dazulernen. Scrum ist das am weitesten verbreitete Framework: Ein kleines Team arbeitet in festen Zyklen namens Sprints von höchstens einem Monat, die jeweils mit einer Planung beginnen und mit einem Review der Arbeit und einer Retrospektive zur Zusammenarbeit des Teams enden. Der Scrum Guide 2020 definiert drei Verantwortlichkeiten: den Product Owner (entscheidet, was am wertvollsten ist), den Scrum Master (hilft dem Team, Scrum wirksam einzusetzen) und die Developers (erledigen die Arbeit). Kanban, für Software aus dem Produktionssystem von Toyota übernommen, hat keine festen Zyklen: Arbeitspakete fließen über ein sichtbares Board (zu erledigen, in Arbeit, Review, erledigt), und das Team begrenzt, wie viele davon gleichzeitig in Arbeit sein dürfen, damit Arbeit fertig wird, bevor neue begonnen wird.

Keiner dieser Ansätze passt für jedes Team, und viele Organisationen mischen sie: Scrum für Produktteams, Kanban für Support und Betrieb, ein eher sequenzieller Plan rund um eine feste regulatorische Frist. Einen Prozess „agil“ zu nennen macht ihn nicht agil; entscheidend ist, ob funktionierende Software oft genug echte Nutzer erreicht, um von ihnen zu lernen.

DevOps: die Verantwortung eines Teams vom Code bis zum Kunden

Traditionell schrieben Entwickler Software, und ein separates Betriebsteam betrieb sie, mit gegensätzlichen Anreizen: Entwickler wurden für Veränderung belohnt, der Betrieb für Stabilität. DevOps ist die Bewegung, benannt auf der ersten DevOpsDays-Konferenz 2009 in Gent, die beide zusammenbringt. Sie ist vor allem eine Kultur der gemeinsamen Verantwortung („you build it, you run it“), gestützt durch Praktiken wie CI/CD, Infrastructure as Code, Monitoring und schuldzuweisungsfreie Auswertung von Vorfällen. Sie ist weder eine Berufsbezeichnung noch ein Werkzeug, auch wenn beides unter dem Namen verkauft wird. Das DORA-Forschungsprogramm ist vor allem dafür bekannt, Delivery-Performance mit vier Schlüsselmetriken zu messen: wie oft ein Team deployt, wie lange eine Änderung bis in die Produktion braucht, wie oft Änderungen fehlschlagen und wie schnell der Dienst nach einem Ausfall wiederhergestellt ist.

Ausgearbeitetes Beispiel: der Weg eines Tippens

Alles in diesem Kapitel kommt in einem einzigen Moment zusammen. Eine Kundin hat in einer Essensliefer-App einen Warenkorb gefüllt und tippt auf Bestellen. Binnen ein oder zwei Sekunden zeigt der Bildschirm „Bestellung bestätigt“, und zwanzig Minuten später vibriert das Telefon: „Ihr Fahrer ist unterwegs“. Hier ist, was Schritt für Schritt geschieht, mit dem Konzept hinter jedem Schritt und dem Ort, an dem es eingeführt wurde.

Warum das für die Architektur wichtig ist

Der Weg eines Tippens nutzt ein Dutzend Komponenten, drei Organisationen sowie synchrone und asynchrone Kommunikation, und er musste trotzdem entworfen werden: Jemand hat entschieden, dass die Zahlung synchron ist und Benachrichtigungen nicht, dass Bestellungen in einer relationalen Datenbank liegen, dass der Service in Containern über zwei Zonen läuft, dass der Zahlungsanbieter hinter einem Modul abgeschottet ist. Zu entscheiden, wie diese Teile angeordnet sind, welche Qualitäten jede Anordnung erreicht und was sie kostet, und festzuhalten, warum, ist Softwarearchitektur. Auch die Art, wie Software entsteht, ist für die Architektur wichtig: Eine Architektur, die sich nicht in Teilen testen oder nicht ohne die Abstimmung von zehn Teams ausliefern lässt, bremst jede Änderung. Kapitel 1 beginnt mit Was Softwarearchitektur ist.