// HEISE ONLINE — HARDWARE & GADGET
Soziotechnische Architektur-Reviews: Teams verstehen, nicht nur Artefakte
Architektur-Reviews betrachten oft nur die Struktur der Software. Viel effizienter und effektiver ist es aber, den Fokus beim Review auf das Team zu legen.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Klassische Architektur-Reviews beschäftigen sich mit dem Code: Architektur gibt dem Code schließlich Struktur. Diese Struktur ist zentral für die Änderbarkeit.
Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.
Metriken machen die Qualität dieser Struktur messbar und ermöglichen die schnelle Analyse auch großer Projekte. Ein System sollte in überschaubar große Bestandteile mit möglichst wenigen Abhängigkeiten aufgeteilt werden. Zu solchen Bestandteilen zählen Klassen, Packages (Sammlungen von Klassen in Java) oder Microservices. Die Größe der Bestandteile und die Anzahl der Abhängigkeiten kann man als Metrik messen und so die Qualität beurteilen.
Besonders schlimm sind zyklische Abhängigkeiten: Wenn beispielsweise zwei Packages wechselseitig voneinander abhängen, kann eine Änderung in einem der Packages das andere beeinflussen. Eigentlich sollten die beiden Packages also getrennt sein – in Wirklichkeit sind sie aber eins. So ein Zyklus ist eine Art „Todsünde“ in der Architektur.
Es gibt aber noch andere Metriken. Man kann auch die zyklomatische Komplexität von Methoden messen. Das ist die Anzahl der möglichen Ausführungspfade durch eine Methode. Jede Fallunterscheidung (if-Statement) ergibt einen weiteren möglichen Ausführungspfad. Mehr Ausführungspfade bedeutet, dass der Code komplexer und schwerer zu verstehen ist.
Aber treffen solche Metriken den Kern der Probleme?
Metriken bergen fast immer Probleme. Nicht selten muss man von einem „Big Ball of Mud“ sprechen. Das ist ein System mit so schlechten Metriken, dass es eigentlich keine echte Strukturierung hat. Wenn niemand mit entsprechenden Werkzeugen die Metriken managt, ergibt sich fast immer ein unstrukturiertes System. Es ist dann trivial herauszufinden, dass ein System schlecht strukturiert ist. Wenn das so einfach ist – welchen Wert hat dieser Einblick?
Eigentlich interessiert uns die Änderbarkeit des Systems. Die Metriken können Hinweise auf eine gute oder schlechte Änderbarkeit geben, aber nicht mehr. Es ist durchaus denkbar, dass ein System mit schlechten Metriken dennoch ausreichend änderbar ist, weil das Team das System schon lange weiterentwickelt und sich an die Strukturierung gewöhnt hat.