“Architektur ist ein Grundpfeiler für gute Testbarkeit!” - Richard Seidl
Vorneweg: Ich bin kein Experte für Software-Architektur. Dafür gibt es andere. Ich bin eher ein Architektur-Anbeter, immer erfreut über neue Pattern, Frameworks und Strategien, die uns hier vorwärtsbringen. Architektur ist für mich auch ein Grundpfeiler guter Software-Qualität. Sie hilft nicht nur den Entwicklern, saubere Software zu schreiben. Sie hilft auch uns Testern und Qualitätsmenschleins bei einem ganz ganz ganz wichtigen Punkt: Testbarkeit.
Ich habe in Projekten schon so oft Aussagen wie diese gehört:
- “Nein, also Unittests können wir nicht schreiben, das gibt die Architektur nicht her”
- “Uh… Performance-Probleme. Ja, das wissen wir, aber die Architektur ändern… weißt, die ist halt historisch gewachsen”
- “Na, an die Schnittstellen kommst du so einfach nicht ran. Und die sind auch nicht wirklich offiziell”
Und so weiter und so fort. Alles Zeichen dafür, dass sich niemand um eine sinnvolle Software-Architektur kümmert oder einfach drauf loscodiert wurde. Das ist am Beginn einer Software auch legitim, aber es muss dann auch recht bald klar sein, welche Strukturen, Schnittstellen und Pattern genutzt werden. Und eine Sicht auf die Architektur muss entstehen.
Ich bin immer wieder fassungslos, wie Teams mit 10, 20, 30 Entwicklern und Testern an Software rumwerkeln und dabei ständig mit diesen technischen Schulden umgehen müssen. Wobei, eigentlich sind es ja gar keine technischen Schulden, sondern organisatorische. Aber lassen wir das mal. Da wird unfassbar viel Geld verbrannt, um mit diesen Unzulänglichkeiten umzugehen, statt zu beginnen, sie zu heilen.
Neben den Projekten, die ganz ohne überlegte Architektur arbeiten, gibt es noch die anderen, die glaube ich einem Grund-Missverständnis aufsitzen. Nämlich, dass eine Software-Architektur zu Beginn mal festgelegt ist und dann für immer gilt.
Das passt in meiner Welt gar nicht. Eine Architektur ist sicher nicht etwas, was ich alle paar Tage umwerfe und neu mache. Aber eine Weiterentwicklung und Fluidity möchte ich schon gerne sehen. Und damit meine ich nicht nur, auf die aktuellste Version des Frameworks zu aktualisieren, sondern die Architektur mit Fragen zu betrachten wie: Wie muss unsere Software-Architektur aussehen,
- damit heutige und morgige Anforderungen einfach implementiert werden können?
- damit sie den Entwicklungsprozess unterstützt?
- damit sie zu neu aufkommenden Themen passt?
Den letzten Punkt finde ich nochmal sehr spannend. Denn neue Innovationen, wie z. B. jetzt gerade MCP-Server im Bereich der KI, entstehen ja aus Projekten und Teams, die aktuelle Architekturen implementiert haben. Und wenn man ebenso aktuelle Architektur-Paradigmen nutzt, ist die Implementierung dieser Features viel einfacher, als wenn die eigene Implementierung den Stand der Technik von vor 10 Jahren hat.
Meiner Meinung nach wird Software-Architektur viel zu sehr unterschätzt. Eigentlich eine Schande bei der Bedeutung, die ihr zusteht.
Also: Sucht mal den Architekten in eurem Team auf und geht gemeinsam einen Kaffee trinken 🙂