In meinem letzten Artikel über die Problematik bei Projekten in die Zukunft gucken zu können, habe ich ja schon darauf hingewiesen, dass im agilen Kontext der Fortschritt durch kurze Experimente kommt. In meiner Vorlesung IT-Management kommen wir dann immer schnell an die Stelle, wie denn jetzt Softwarearchitekturen entstehen. Für die Nicht-ITler: Die Architektur ist quasi wie der Bauplan für die Software. Schließlich lernen die Informatikstudenten in mehreren Vorlesungen, wie eine gute Softwarearchitektur aufgebaut wird und wie wichtig es ist, das im Voraus zu machen. Auch hier ist wieder die Vorannahme, das vor der Entwicklung bekannt ist, wie das Ergebnis aussieht und deshalb wird dann die beste Architektur dafür gewählt.
Ich habe in meiner Studienzeit mal für ein Unternehmen gearbeitet, für das ich ein Verwaltungs-System entwickeln sollte. Mein Kontakt und Auftraggeber hat mir vorher genau erklärt, wie alles funktionieren soll und ich habe, wie ich es in der Uni gelernt habe, eine passende Architektur dazu entworfen. Ich fand das so eine tolle Lösung und hab mich gefreut das Anwenden zu können, was ich in der Uni lerne. Während des Projektverlaufs und insbesondere zum Ende hin, stellte sich jedoch heraus, dass die Anforderungen falsch und unvollständig waren. Ich musste deshalb immer wieder Korrekturen machen und den Funktionsumfang erweitern. Leider passte die Architektur nur überhaupt nicht zu dem, was jetzt letztlich verlangt wurde. Irgendwie habe ich das dann noch da reingequetscht nur das Ergebnis war Softwaretechnisch echt nicht toll. Selbstverständlich war aufgrund des Zeit- und Kostendrucks seitens des Auftraggebers explizit nicht gewünscht, dass ich die Architektur noch einmal überarbeite.
Ist jetzt also die gesamte Softwaretechnik überflüssig oder falsch? Wir können nunmal das Ergebnis zu Beginn nicht kennen – in komplexen Umgebungen. Ist alles falsch was die Studenten da lernen? Nein – natürlich nicht. Das agile Manifest fordert in den Prinzipien ganz explizit technische Exzellenz. Es ist sehr wichtig, dass die Entwickler ein gutes Verständnis von Softwarearchitekturen haben, damit sie überhaupt beurteilen können, wie qualitativ ihre Lösung ist. Nur wie kommt es jetzt zu einer guten Architektur, wenn wir diese nicht im Voraus planen? Indem wir mithilfe unserer Kenntnisse und einem besonderen Augenmerk die Architektur immer mit entwickeln und uns kontinuierlich auch Zeit dafür nehmen, die Softwarequalität auf einem guten Standard zu halten. Die Kenntnisse der Softwaretechnik sind dann eben die Grundlage, um kontinuierlich die passenden Lösungen und Anpassungen zu finden. Dazu gibt es heutzutage einige gute Lösungen und Stichworte, die in diesem Bereich weiterhelfen: Clean Code, Clean Architecture, Test Driven Development (TDD) und Behaviour Driven Development (BDD) fallen mir da als erstes ein.
Schreibe einen Kommentar