Softwareentwicklung – APIs & Architektur

Software entsteht selten in einem Zug. Am Anfang steht die Klärung der Anforderungen: Welches Problem soll gelöst werden, für wen, und woran erkennt man den Erfolg? Erst danach folgt der Entwurf, in dem Zuständigkeiten, Datenflüsse und Schnittstellen festgelegt werden. Die eigentliche Umsetzung ist häufig der kürzeste Abschnitt — und der Betrieb der längste.

Weil sich Anforderungen ändern, arbeiten die meisten Teams heute in kurzen Zyklen statt in einem großen Durchlauf. Statt monatelang zu planen und am Ende ein fertiges Produkt zu übergeben, entstehen kleine, lauffähige Zwischenstände, die früh Rückmeldung erzeugen. Der Vorteil ist weniger die Geschwindigkeit als die Fehlertoleranz: Ein falsch verstandener Wunsch kostet eine Woche statt ein halbes Jahr.

Wichtig bleibt trotzdem die Vorarbeit. Die teuersten Fehler in Projekten sind fast nie Tippfehler im Code, sondern Missverständnisse darüber, was gebaut werden sollte.

Architektur beschreibt, wie eine Anwendung in Teile zerlegt ist und wie diese Teile miteinander reden. Zwei Begriffe tragen dabei fast alles: Kopplung — wie stark ein Teil von anderen abhängt — und Kohäsion — wie gut zusammengehört, was in einem Teil steckt. Angestrebt wird lose Kopplung bei hoher Kohäsion, weil sich solche Systeme ändern lassen, ohne dass an unerwarteter Stelle etwas zerbricht.

Die Grundsatzfrage lautet meist: ein zusammenhängendes System oder viele eigenständige Dienste? Ein gut strukturierter Monolith ist einfacher zu betreiben, zu testen und zu verstehen und für die allermeisten Projekte die richtige Antwort. Verteilte Dienste lösen ein organisatorisches Problem — mehrere Teams wollen unabhängig ausliefern — und erkaufen das mit Netzwerklatenz, komplizierterer Fehlersuche und aufwendigem Betrieb.

Gute Architektur erkennt man weniger an Diagrammen als daran, dass eine neue Anforderung an genau einer Stelle umgesetzt werden kann.

Code wird deutlich häufiger gelesen als geschrieben. Deshalb zählen sprechende Namen, überschaubare Funktionen und ein vorhersehbarer Aufbau mehr als jeder clevere Einzeiler. Was der Code tut, steht im Code selbst; Kommentare beantworten dagegen die Frage, warum eine Lösung so und nicht anders gewählt wurde.

Tests sind dabei kein Selbstzweck, sondern die Voraussetzung für Veränderung. Wer eine Anwendung ohne automatisierte Prüfungen umbaut, muss hoffen; wer sie hat, kann es einfach ausprobieren. Sinnvoll ist eine Mischung: viele schnelle Prüfungen einzelner Bausteine, weniger Prüfungen des Zusammenspiels und einige wenige Durchläufe der wichtigsten Abläufe von Anfang bis Ende.

Der Begriff technische Schuld beschreibt bewusst oder unbewusst aufgeschobene Aufräumarbeit. Wie bei echten Schulden sind kleine Beträge unproblematisch, solange man sie zurückzahlt. Gefährlich wird es, wenn die Zinsen — also der Mehraufwand bei jeder Änderung — den Fortschritt auffressen. Regelmäßiges Umstrukturieren bei laufendem Betrieb ist deshalb Teil der Arbeit, kein Sonderprojekt.

Ab der zweiten beteiligten Person ändert sich die Arbeit grundlegend. Änderungen fließen dann nicht mehr direkt in den gemeinsamen Stand, sondern laufen über abgegrenzte Zweige und werden als überschaubare Pakete zur Prüfung gestellt. Ein solches Review ist kein Misstrauensvotum, sondern die günstigste Stelle, an der Missverständnisse, Randfälle und unklare Namen noch auffallen — und zugleich der wirksamste Weg, Wissen im Team zu verteilen.

Damit das trägt, braucht es gemeinsame Vereinbarungen: ein einheitlicher Formatierungsstil, der automatisch durchgesetzt wird, statt in Diskussionen zu landen; eine geteilte Vorstellung davon, wann eine Aufgabe wirklich fertig ist — umgesetzt, geprüft, dokumentiert, ausgeliefert; und eine nachvollziehbare Verbindung zwischen Anforderung, Änderung und Begründung.

Schätzungen bleiben trotzdem schwierig. Verlässlicher als eine Stundenangabe ist, Aufgaben so klein zu schneiden, dass sie in wenigen Tagen abschließbar sind, und aus dem tatsächlichen Durchsatz der letzten Wochen auf den nächsten zu schließen.