Wie ich bereits in einem früheren Artike (oder auch hier) erwähnt habe, beginnen die wichtigsten Fragen in der Software-Architektur mit „Was wäre, wenn…?“. Wird eine dieser Fragen übergangen oder vorschnell beantwortet, ohne gründlich darüber nachzudenken, darf man sich später nicht wundern, wenn bereits kleine Änderungen – etwa ein neues Feature oder eine Kundenanpassung – mühsame und kostspielige Anpassungen an unzähligen Stellen im Code nach sich ziehen.
Plötzlich müssen Methoden geändert, Signaturen angepasst und Rückgabewerte modifiziert werden. Ganze Datentypen, inklusive ihrer Eigenschaften, Methoden und Events, müssen umgestaltet werden. Dadurch verlieren bestehende Unit-Tests ihre Gültigkeit, müssen umgeschrieben oder gar entfernt werden. Noch schlimmer: Neue Unit-Tests passen oft nicht mehr nahtlos in das ursprünglich durchdachte Konzept.
Das TDD-Paradigma, kann hier paradoxerweise zu Problemen führen. Denn wenn die Architektur bereits auf wackligen Beinen steht, entstehen „Risse“ nicht nur im Code, sondern auch in der Benutzerführung – spürbar durch inkonsistente Steuerung oder unerwartetes Verhalten der Oberfläche bei Desktop-Anwendungen und Mobile-Apps.
Flexibilität: Was sich immer ändern wird
Manche Dinge ändern sich zwangsläufig – und sollten daher von vornherein leicht konfigurierbar oder erweiterbar sein:
- Theme, Look & Feel – weil sich Design-Standards weiterentwickeln.
- Sprachunterstützung – denn neue Märkte bedeuten neue Anforderungen.
- Datenexport – weil Kunden irgendwann ein anderes Format benötigen.
- Diagramme und Reports – da sich Analyse- und Visualisierungsanforderungen ändern.
- Kommunikation mit Schnittstellen und Protokollen – weil neue Technologien und Standards entstehen.
Unwahrscheinliche Änderungen? Vielleicht doch nicht!
Dann gibt es Dinge, bei denen man glaubt, sie würden nie oder nur in den seltensten Fällen geändert werden – und doch geschieht es irgendwann:
- Der Kunde will Produktionsdaten in einer exotischen Datenbank oder einem speziellen Dateiformat speichern.
- Eine „unbedeutende“ Zahl soll plötzlich auf dem Bildschirm angezeigt oder eine neue Konfigurationsmöglichkeit für die Nachtschicht integriert werden.
- Eine günstigere SPS oder Industrie-Kamera eines unbekannten Herstellers muss eingebunden werden – leider nicht ganz standardkonform.
Ob, wann und wie solche Änderungen kommen, ist nur eine Frage der Zeit.
Architektur ist wie Schach – erst denken, dann ziehen!
Ein guter Software-Architekt verhält sich wie ein professioneller Schachspieler: Er nimmt sich Zeit für das Vorausdenken, prüft verschiedene Szenarien und fragt sich „Was wäre, wenn…?“, bevor er zur Tastatur greift.
Denn grobe Architekturfehler verhalten sich wie unbedachte Züge im Schach: Ein frühzeitiger Fehlgriff kann zum Schachmatt führen – oder die gesamte Strategie unnötig kompliziert und mühselig machen. Einmal falsch platziert, steht die Figur im Weg und macht jede weitere Planung schwieriger.
Besser also, man nimmt sich die Zeit für eine durchdachte Architektur – bevor man sich später durch einen Flickenteppich aus Workarounds kämpft.
