Einfachheit, Umkehrbarkeit und das Messen von Struktur

Zwei Arten von Komplexität

In „No Silver Bullet: Essence and Accidents of Software Engineering“ (vorgestellt 1986 auf dem IFIP World Computer Congress und 1987 in IEEE Computer veröffentlicht) teilte Fred Brooks die Schwierigkeiten der Softwareentwicklung in zwei Arten ein. Essenzielle Komplexität gehört zum Problem: die tatsächlichen Regeln der Mehrwertsteuer, die tatsächliche Vielfalt von Versicherungsprodukten, die tatsächlichen Arten, auf die eine Lieferung scheitern kann. Kein Entwurf kann sie beseitigen, ohne zu ändern, was das System tut. Akzidentelle Komplexität entsteht aus der Art, wie wir die Lösung bauen: Sprachen, Werkzeuge, Frameworks, Deployment-Maschinerie, Workarounds und Strukturen, die komplizierter sind, als das Problem verlangt. Brooks argumentierte, dass höhere Programmiersprachen und andere Fortschritte bereits viel akzidentelle Schwierigkeit beseitigt hätten, sodass keine einzelne neue Technik innerhalb eines Jahrzehnts eine Verbesserung um das Zehnfache bringen würde.

Für Architekten ist die Unterscheidung ein tägliches Werkzeug. Essenzielle Komplexität muss platziert werden: dort, wo die Menschen, die sie verstehen, daran arbeiten können, hinter einer Grenze, die verhindert, dass sie in alles andere durchsickert (ein Preismodul, ein Steuerservice). Akzidentelle Komplexität muss beseitigt oder verhindert werden: Jeder zusätzliche Service, jede Queue, jeder Cache, jede Abstraktionsschicht und jede Konfigurationsoption fügt etwas davon hinzu, und jedes Element muss seinen Platz verdienen, indem es ein echtes Problem löst. Der Essay „Out of the Tar Pit“ (2006) von Ben Moseley und Peter Marks trieb die Idee weiter und benannte veränderlichen Zustand und Kontrollfluss als wichtige Quellen akzidenteller Komplexität; das ist ein Grund, warum funktionale und ereignisgesteuerte Entwürfe, die geteilten Zustand begrenzen, beliebt sind.

Der Rest dieses Abschnitts behandelt die Prinzipien, die akzidentelle Komplexität gering halten (KISS, YAGNI, richtig verstandenes DRY, Umkehrbarkeit), und die Messungen, die Ihnen helfen, Struktur objektiv zu sehen, samt ihren Grenzen.

KISS und YAGNI

KISS, meist ausgeschrieben als „keep it simple, stupid“, ist eine Designmaxime, die 1960 in der US Navy belegt ist und mit Kelly Johnson in Verbindung gebracht wird, dem leitenden Ingenieur der Skunk Works von Lockheed, der verlangt haben soll, dass Düsenflugzeuge im Feld von einem durchschnittlichen Mechaniker mit einer Handvoll Werkzeuge repariert werden können. Für Software gilt dasselbe: Ein Entwurf ist gut, wenn die Menschen, die ihn betreiben und reparieren müssen, oft um 3 Uhr morgens unter Druck, ihn verstehen können. Einfach heißt nicht leicht oder naiv. Es heißt wenige Konzepte, wenige bewegliche Teile und wenige Sonderfälle für das zu lösende Problem.

YAGNI („you aren’t gonna need it“, „Sie werden es nicht brauchen“) stammt aus dem Extreme Programming der späten 1990er-Jahre: Bauen Sie keine Fähigkeiten für Bedürfnisse, die Sie nur vermuten. Martin Fowlers Analyse ist nützlich, weil sie die Kosten benennt, die entstehen, wenn man es ignoriert. Da sind die Kosten des Bauens des vermuteten Features; die Kosten der Verzögerung, weil stattdessen etwas Wertvolles nicht gebaut wurde; die Kosten des Mitschleppens, weil jede spätere Änderung den zusätzlichen Code berücksichtigen muss; und, falls die Vermutung falsch war, die Kosten der Reparatur. Selbst wenn die Vermutung sich als richtig erweist, wurde das Feature mit weniger Wissen gebaut, als Sie später gehabt hätten.

Zwei Einschränkungen verhindern, dass YAGNI zur Ausrede wird. Erstens gilt es für Features und spekulative Flexibilität, nicht für die Praktiken, die Änderungen günstig machen. Automatisierte Tests, Refactoring, Continuous Delivery und klare Modulgrenzen sind es, die das Aufschieben von Features sicher machen; wer sie im Namen von YAGNI weglässt, verwandelt Aufschub in Schulden. Zweitens sind manche Entscheidungen Einwegtüren (Abschnitt 1.6). Die Wahl eines Datenmodells, der Form einer öffentlichen API, eines Mandantenmodells oder einer Sicherheitsgrenze ist kein Feature, das Sie später zu denselben Kosten ergänzen können. Dort ist Vorausdenken keine Spekulation, sondern die Aufgabe des Architekten.

DRY meint Wissen, nicht Text

Andy Hunt und Dave Thomas führten DRY in The Pragmatic Programmer (1999; Jubiläumsausgabe zum 20. Jahrestag 2019) mit dieser Definition ein: Jedes Stück Wissen muss innerhalb eines Systems eine einzige, eindeutige, maßgebliche Darstellung haben. Das Schlüsselwort ist Wissen. Wenn der Mehrwertsteuersatz, die Regel für eine gültige Postleitzahl oder die Bedeutung eines Bestellstatus an mehreren Stellen steht, muss man für eine Änderung jede Kopie finden, und die Kopien werden auseinanderdriften. Die Ausgabe von 2019 betont, dass es bei DRY um die Duplizierung von Wissen und Absicht geht, nicht um Codezeilen, die zufällig gleich aussehen.

Der häufige Missbrauch geht in die andere Richtung. Zwei Funktionen, die gleich aussehen, werden zusammengelegt, weil sie gleich aussehen, obwohl sie unterschiedliches Wissen darstellen, das sich aus unterschiedlichen Gründen ändern wird: Die Liefergebührenregel und die Restaurantprovisionsregel multiplizieren heute beide eine Summe mit einem Prozentsatz, aber sie gehören zu verschiedenen Akteuren (Finanzen und Partnermanagement) und werden auseinanderlaufen. Sie zusammenzulegen koppelt zwei Konzepte, die die Domäne getrennt hält: Beide hängen nun von einer gemeinsamen Funktion ab, sodass eine für die eine Regel gewünschte Änderung stillschweigend die andere ändert. In den Begriffen von Abschnitt 3.6 erzeugt das Connascence, wo das Problem keine hat (eine gemeinsame Funktion ist nur dann die richtige Lösung, wenn beide Seiten wirklich dasselbe berechnen müssen); es ist außerdem ein Verstoß gegen das Single-Responsibility-Prinzip (Abschnitt 3.5). Sandi Metz’ bekannter Rat lautet, Duplizierung der falschen Abstraktion vorzuziehen, weil eine falsche gemeinsame Abstraktion Parameter und Bedingungen ansammelt, bis niemand mehr wagt, sie zu ändern. Viele Teams nutzen die Dreierregel: eine zweite Kopie tolerieren und eine Abstraktion herausziehen, wenn die dritte auftaucht und das gemeinsame Wissen klar ist.

Auf Architekturebene wird die Abwägung explizit. Eine gemeinsame Bibliothek, die jeder Service nutzen muss, beseitigt duplizierten Code, koppelt aber die Release-Zyklen der Services. Viele Microservice-Organisationen akzeptieren bewusst duplizierten Code (kleine Hilfsfunktionen, in jeden Service kopiert), bestehen aber auf genau einem Verantwortlichen für dupliziertes Wissen (den kanonischen Kundendatensatz, die Steuerregeln). Fragen Sie bei jeder Duplizierung: Wenn sich diese Regel ändert, müssen sich dann alle Kopien gemeinsam ändern? Wenn ja, ist es dupliziertes Wissen und sollte einen Verantwortlichen haben. Wenn nein, ist es zufällige Ähnlichkeit und kann bleiben.

Umkehrbarkeit und die Kosten von Optionen

Einfachheit hat eine zeitliche Dimension. Ein Entwurf, der heute einfach, aber unmöglich zu ändern ist, ist nicht günstig; ein Entwurf voller Flexibilität, die niemand nutzt, ist es auch nicht. Das nützliche Konzept ist Umkehrbarkeit: Wie teuer wäre es, diese Entscheidung später rückgängig zu machen oder zu ändern? Abschnitt 1.6 hat Einwegtüren und Zweiwegtüren eingeführt. Hier geht es darum, dass sich Flexibilität wie eine Finanzoption verhält: Sie hat jetzt einen Preis (zusätzlicher Code, zusätzliche Abstraktion, zusätzliche Betriebskosten) und einen Wert, der davon abhängt, wie wahrscheinlich und wie teuer die Änderung ist, gegen die sie absichert.

Daraus ergibt sich eine Faustregel, die YAGNI mit vorausschauendem Denken versöhnt. Bezahlen Sie für eine Option nur, wenn die Änderung einigermaßen wahrscheinlich ist oder ohne die Option sehr teuer wäre, und wenn die Option selbst günstig ist. Einen Zahlungsanbieter hinter einer eigenen Schnittstelle zu kapseln kostet einen Tag und schützt vor einer Änderung, die sowohl plausibel als auch teuer ist: eine gute Option. Eine Multi-Cloud-Abstraktionsschicht für ein Start-up mit einem einzigen Kunden zu bauen ist eine teure Option gegen eine unwahrscheinliche Änderung. Oft ist die günstigste Option einfach gute Modularität: Gut gesetzte Grenzen halten viele künftige Änderungen lokal, ohne dass jemand sie vorhersagen muss; das ist Parnas’ ursprüngliches Argument für Information Hiding (Abschnitt 3.1).

Struktur messen: zyklomatische Komplexität

Das Urteil über Einfachheit wird besser, wenn es sich auf Messungen stützt. Die älteste weit verbreitete Codemetrik ist die zyklomatische Komplexität, die Thomas McCabe in „A Complexity Measure“ (IEEE Transactions on Software Engineering, 1976) einführte. Sie betrachtet eine Funktion als Kontrollflussgraphen, mit Knoten für Codeblöcke und Kanten für mögliche Kontrollübergänge, und zählt die linear unabhängigen Pfade durch ihn: M = E − N + 2P, wobei E die Zahl der Kanten, N die Zahl der Knoten und P die Zahl der Zusammenhangskomponenten ist (1 für eine einzelne Funktion). Bei strukturiertem Code mit einem Einstiegspunkt entspricht dies der Zahl der Entscheidungspunkte plus eins.

McCabe schlug 10 als vernünftige Obergrenze für ein Modul vor. Der spätere NIST-Bericht zum strukturierten Testen von Arthur Watson und McCabe (1996) merkt an, dass erfahrene Teams Grenzen bis 15 erfolgreich verwendet haben, und empfiehlt eine schriftliche Begründung, wann immer ein Modul die gewählte Grenze überschreitet. Werkzeuge zur statischen Analyse wie radon oder das mccabe-Plugin für flake8 in Python, die ESLint-Regel complexity in JavaScript und SonarQube berechnen sie automatisch. Die Werkzeuge unterscheiden sich in Details, etwa ob jedes and oder or in einer Bedingung als zusätzliche Entscheidung zählt; vergleichen Sie daher nur Zahlen aus demselben Werkzeug.

def delivery_fee(total: int, distance_km: float, priority: bool) -> int:
    if total >= 2500:          # decision 1: free delivery over 25 pounds
        return 0
    fee = 299
    if distance_km > 5:        # decision 2
        fee += 100
    if priority:               # decision 3
        fee += 200
    return fee

Struktur jenseits von Funktionen messen

Die zyklomatische Komplexität sieht jeweils nur eine Funktion. Architekten brauchen Maße dafür, wie Module zueinander stehen.

Kopplungs- und Stabilitätsmetriken. Abschnitt 3.4 (Abhängigkeiten steuern) hat afferente und efferente Kopplung eingeführt, die Instabilität I = Ce / (Ca + Ce), die Abstraktheit und den Abstand von der Hauptreihe. Sie lassen sich günstig aus Importgraphen berechnen und decken gut Komponenten auf, von denen viele abhängen, die aber selbst von volatilem Code abhängen; außerdem finden sie Abhängigkeitszyklen.

Kohäsionsmetriken. Die Familie der LCOM-Metriken (lack of cohesion of methods, mangelnde Kohäsion der Methoden) schätzt ab, ob eine Klasse eine Verantwortlichkeit trägt oder mehrere. Die ursprüngliche Version von Shyam Chidamber und Chris Kemerer (1994) vergleicht Methodenpaare danach, ob sie gemeinsame Felder nutzen. Eine weit verbreitete spätere Variante, LCOM4 von Martin Hitz und Behzad Montazeri, baut einen Graphen, in dem Methoden verbunden sind, wenn sie ein Feld teilen oder die eine die andere aufruft, und zählt die zusammenhängenden Gruppen. Eine Klasse mit LCOM4 = 1 ist in sich geschlossen; eine Klasse mit LCOM4 = 3 sind drei Klassen, die sich eine Datei teilen. Zum Beispiel hat eine Klasse Customer, deren update_address und format_address die Adressfelder nutzen, deren add_points und points_balance die Treuefelder nutzen und deren send_newsletter nur das E-Mail-Feld nutzt, LCOM4 = 3, was auf die Verantwortlichkeiten Adresse, Treueprogramm und Marketing hindeutet.

Historienbasierte Metriken. Die Versionsverwaltung zeichnet auf, wie sich das System tatsächlich ändert, was die statische Analyse nicht sehen kann. Change Coupling findet Dateien oder Services, die wiederholt gemeinsam committet werden: Wenn sich pricing.py und invoice_template.html in 70 % der Commits gemeinsam ändern, sind sie gekoppelt, ob eine die andere importiert oder nicht, und die Kopplung kann eine Servicegrenze überschreiten, die sie eigentlich trennen sollte. Hotspots kombinieren Änderungshäufigkeit mit Komplexität, um Code zu finden, der zugleich schwer zu bearbeiten ist und häufig bearbeitet wird; Adam Tornhills Your Code as a Crime Scene (2015; zweite Auflage 2024) hat die Technik bekannt gemacht. Abschnitt 1.7 über technische Schulden hat gezeigt, wie Hotspots die Tilgung auf die Schulden lenken, die die höchsten Zinsen kosten.

Goodharts Gesetz und die Grenzen von Metriken

Jede der obigen Metriken ist ein Stellvertreter für etwas, das uns wichtig ist, das wir aber nicht direkt messen können: wie leicht sich das System verstehen und ändern lässt. Goodharts Gesetz, benannt nach dem Ökonomen Charles Goodhart (1975) und am bekanntesten in der Formulierung der Anthropologin Marilyn Strathern von 1997, warnt: Wenn ein Maß zum Ziel wird, hört es auf, ein gutes Maß zu sein. Menschen optimieren die Zahl, nicht die Eigenschaft.

Softwareteams erleben das ständig. Eine harte Grenze von zyklomatischer Komplexität 10 erzeugt Funktionen, die an willkürlichen Stellen aufgeteilt sind und jeweils die Prüfung bestehen, während die Logik schwerer nachvollziehbar wird. Ein Abdeckungsziel von 80 % erzeugt Tests, die Code ausführen, ohne irgendetwas zu prüfen. Eine Regel, dass keine Klasse 200 Zeilen überschreiten darf, erzeugt Klassen, die in OrderHelper und OrderHelper2 aufgeteilt sind. Ein Ziel von „null Zyklen“ lässt sich erreichen, indem man Code in ein Sammelbecken-Paket common verschiebt, von dem alles abhängt.

Fachleute nutzen Metriken auf drei Arten, die Manipulation erschweren. Sie betrachten Trends statt absoluter Schwellenwerte (die Komplexität im Zahlungsmodul hat sich in sechs Monaten verdoppelt: warum?). Sie nutzen Metriken, um Gespräche anzustoßen und Reviews zu priorisieren, nicht, um Menschen zu benoten. Und sie kombinieren Metriken, die in verschiedene Richtungen ziehen, etwa Komplexität mit Änderungshäufigkeit oder Kopplung mit Teamverantwortung, sodass sich keine einzelne Zahl auf Kosten der anderen optimieren lässt.

Fitness Functions: Struktur prüfbar machen

Manche strukturellen Regeln sind klar genug, um sie zu automatisieren, und dann hängen sie nicht mehr von Wachsamkeit ab. Building Evolutionary Architectures von Neal Ford, Rebecca Parsons und Patrick Kua (2017; zweite Auflage 2022 mit Pramod Sadalage) nennt solche Prüfungen Fitness Functions: objektive, automatisierte Tests eines Architekturmerkmals, die in der Build-Pipeline oder gegen das laufende System laufen. Beispiele für Struktur sind: keine Abhängigkeitszyklen zwischen Paketen der obersten Ebene; das Domänenpaket importiert nichts aus den Web- oder Datenbankpaketen; keine Funktion über Komplexität 15 ohne ausdrückliche Ausnahme; kein Service liest die Datenbanktabellen eines anderen Service.

Werkzeuge wie ArchUnit (Java), import-linter (Python) und dependency-cruiser (JavaScript und TypeScript) drücken diese Regeln als Code aus; Abschnitt 3.4 hat Beispiele gegeben. Der Unterschied zu einer Dashboard-Metrik ist, dass eine Fitness Function eine Entscheidung kodiert, die das Team bereits getroffen hat; wird sie verletzt, scheitert der Build und erzwingt eine bewusste Wahl: den Code korrigieren oder die Regel ändern und festhalten, warum. Die vollständige Behandlung, einschließlich Fitness Functions für Performance, Sicherheit und andere Qualitäten, finden Sie in Fitness Functions und evolutionäre Architektur.

[importlinter]
root_package = shop

[importlinter:contract:domain-is-pure]
name = Domain must not depend on infrastructure
type = forbidden
source_modules =
    shop.domain
forbidden_modules =
    shop.infrastructure
    shop.web