Kontinuierliche Architekturvalidierung

Wenn Systeme wachsen oder über einen längeren Zeitraum weiterentwickelt werden, aber deren Codebasis nicht regelmäßig mit der geplanten Architektur verglichen wird, droht die Architektur des Systems zu erodieren, bis sie kaum noch im Code wiederzufinden ist. Durch kontinuierliche Architekturvalidierung kann dies verhindert werden. Dabei wird die in der Codebasis vorliegende Struktur bestehend aus Modulen und deren Abhängigkeiten mit der geplanten Struktur verglichen, um Architekturverstöße festzustellen.
In vielen Projekten sieht die Architektur im Pflichtenheft durchdacht und manchmal sogar elegant aus. Doch entscheidend ist die tatsächliche Architektur, die später in der Codebasis vorliegt. Das Problem ist, dass die ursprünglich geplante und zu Beginn der Entwicklung auch realisierte Architektur im weiteren Verlauf der Entwicklung erodieren kann, falls keine entsprechenden Maßnahmen ergriffen werden, um dies gezielt zu verhindern. Dieses Phänomen ist allgemein bekannt als „Softwareerosion“. Mit diesem Begriff erhält der schleichende Verfall eines Softwaresystems durch zunehmende Entropie einen anschaulichen Namen. Gründe für dieses Problem sind beispielsweise neue Anforderungen, die unter Zeitdruck mit Workarounds umgesetzt werden. Auch bei der Behebung von Fehlern kann durch Unwissenheit die Architektur verletzt werden, wenn zum Beispiel das ursprüngliche Entwicklungsteam nicht mehr zur Verfügung steht. Aber der wohl wichtigste Grund ist fehlender Überblick, denn dieser kann in einer Codebasis mit Tausenden Klassen und Hunderten Packages leicht verlorengehen.
(Den kompletten Artikel finden Sie im Java-Magazin 10.2014)
Hinterlasse einen Kommentar