© Excellent backgrounds/Shutterstock.com
Java Magazin
Bücher

Langlebige Software-Architekturen

Software schreiben ist so einfach, dass dies jeder kann. Eine solche Überzeugung bei vielen Menschen konstatiert Carola Lilienthal. Eines ihrer Schlüsselerlebnisse war der Besuch in einem Institut: Physiker führen ihre Arbeiten und Experimente mit Software durch, die nicht von ausgebildeten Informatikern, sondern von ihnen selbst erstellt wurde. Kann man umgekehrt einen Informatiker physische Experimente durchführen lassen? Schwer vorstellbar, wo bleibt denn da die Ausbildung?

Michael Müller


Dieses Programmieren-kann-jeder-Phänomen habe sie in weiten Teilen ihres Berufslebens begleitet. Nicht nur Physiker, auch Mathematiker, Ingenieure, Wirtschaftswissenschaftler und Wirtschaftsinformatiker denken so. Ja sogar viele Informatiker, so die Autorin, die in ihrem Studium nur wenig oder gar keine Softwarearchitektur belegt hätten. Damit hat sie nach wenigen Seiten den Kern Ihrer Aussage erreicht: Zu langlebiger Software gehören nicht geniale Algorithmen, sondern in erster Linie eine vernünftige Architektur. In diesem Zusammenhang spricht sie auch von technischen Schulden. Hier geht es bekanntermaßen um Designentscheidungen, die entgegen bestimmten Regeln getroffen werden, um Software zum jeweiligen Zeitpunkt schneller entwickeln zu können. Es wird sozusagen ein technischer Kredit aufgenommen, der später zurückzuzahlen ist.Wenn die Autorin vom Aufspüren technischer Schulden spricht, so meint sie damit die Analyse von Software gegen die Sollarchitektur. Und dabei ist es egal, ob hier bewusst technische Schulden eingegangen wurden oder ob von vornherein eher schlampig mit der Architektur umgegangen oder erst gar keine definiert wurde. Analysierbare Regelverletzungen sind für sie zyklische Beziehungen, falsche Zuweisung zu einer Schicht, sowie Zugriffe entgegen der Schichtung. Dies spürt sie mithilfe des Sotographen auf. Dieser stellt die Beziehungen grafisch dar, wobei Regelverletzungen rot eingefärbt werden. Ein eindrucksvolles Werkzeug für das konkrete Projekt. In einem Buch jedoch, das von vielen Projekten recht unkonkret berichtet, häufen sich die Bilder, in denen Packages und Schichten, sowie deren Zugriffsrichtungen dargestellt werden. Mal sind es andere Schichten, mal mehr oder weniger rote Beziehungen, doch irgendwann lässt das Interesse daran nach, wenn der Leser zum wiederholten Male vernimmt, dass durch das Verschieben einer Methode oder Packages die Zahl der zirkulären Referenzen vermindert werden konnte. Der Leser sieht es nicht, da keinerlei Software gezeigt wird. Hier wird das ältere Buch von Ulf Fildebrandt „Software modular bauen“ des gleichen Verlags deutlich konkreter und zeigt auf, wie der Entwickler vorzugehen hat.Lilienthal bewegt sich auf einem deutlich abstrakteren Niveau. Natürlich sind die Darstellungen des Sotographen nicht das einzige, und das Buch bietet viele wichtige und interessante Informationen, doch weniger Wiederholungen hätten hier gut getan. Vornehmlich im Mittelteil des Buchs findet der Leser diese anderen Aspe...

Java Magazin
Bücher

Langlebige Software-Architekturen

Software schreiben ist so einfach, dass dies jeder kann. Eine solche Überzeugung bei vielen Menschen konstatiert Carola Lilienthal. Eines ihrer Schlüsselerlebnisse war der Besuch in einem Institut: Physiker führen ihre Arbeiten und Experimente mit Software durch, die nicht von ausgebildeten Informatikern, sondern von ihnen selbst erstellt wurde. Kann man umgekehrt einen Informatiker physische Experimente durchführen lassen? Schwer vorstellbar, wo bleibt denn da die Ausbildung?

Michael Müller


Dieses Programmieren-kann-jeder-Phänomen habe sie in weiten Teilen ihres Berufslebens begleitet. Nicht nur Physiker, auch Mathematiker, Ingenieure, Wirtschaftswissenschaftler und Wirtschaftsinformatiker denken so. Ja sogar viele Informatiker, so die Autorin, die in ihrem Studium nur wenig oder gar keine Softwarearchitektur belegt hätten. Damit hat sie nach wenigen Seiten den Kern Ihrer Aussage erreicht: Zu langlebiger Software gehören nicht geniale Algorithmen, sondern in erster Linie eine vernünftige Architektur. In diesem Zusammenhang spricht sie auch von technischen Schulden. Hier geht es bekanntermaßen um Designentscheidungen, die entgegen bestimmten Regeln getroffen werden, um Software zum jeweiligen Zeitpunkt schneller entwickeln zu können. Es wird sozusagen ein technischer Kredit aufgenommen, der später zurückzuzahlen ist.Wenn die Autorin vom Aufspüren technischer Schulden spricht, so meint sie damit die Analyse von Software gegen die Sollarchitektur. Und dabei ist es egal, ob hier bewusst technische Schulden eingegangen wurden oder ob von vornherein eher schlampig mit der Architektur umgegangen oder erst gar keine definiert wurde. Analysierbare Regelverletzungen sind für sie zyklische Beziehungen, falsche Zuweisung zu einer Schicht, sowie Zugriffe entgegen der Schichtung. Dies spürt sie mithilfe des Sotographen auf. Dieser stellt die Beziehungen grafisch dar, wobei Regelverletzungen rot eingefärbt werden. Ein eindrucksvolles Werkzeug für das konkrete Projekt. In einem Buch jedoch, das von vielen Projekten recht unkonkret berichtet, häufen sich die Bilder, in denen Packages und Schichten, sowie deren Zugriffsrichtungen dargestellt werden. Mal sind es andere Schichten, mal mehr oder weniger rote Beziehungen, doch irgendwann lässt das Interesse daran nach, wenn der Leser zum wiederholten Male vernimmt, dass durch das Verschieben einer Methode oder Packages die Zahl der zirkulären Referenzen vermindert werden konnte. Der Leser sieht es nicht, da keinerlei Software gezeigt wird. Hier wird das ältere Buch von Ulf Fildebrandt „Software modular bauen“ des gleichen Verlags deutlich konkreter und zeigt auf, wie der Entwickler vorzugehen hat.Lilienthal bewegt sich auf einem deutlich abstrakteren Niveau. Natürlich sind die Darstellungen des Sotographen nicht das einzige, und das Buch bietet viele wichtige und interessante Informationen, doch weniger Wiederholungen hätten hier gut getan. Vornehmlich im Mittelteil des Buchs findet der Leser diese anderen Aspe...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang