Alle guten Dinge sind drei! Es geht weiter in unserer Anti-Pattern Reihe, in der wir gängige Fehler aus der Softwaretechnik aufzeigen und Tipps geben, wie man sie zukünftig vermeidet beziehungsweise nachträglich behebt. Diesmal geht es darum wie man das Rad neu erfindet, beziehungsweise wie man es besser nicht macht, denn wer immer weiter dreht, dreht auch langsam durch.

Bei unserer 3-tägigen Grundausbildung für Softwarearchitekten, dem Foundation Level Training, bekommst du das nötige Know How, um von Anfang an gute und überschaubare Lösungsmuster zu entwickeln. Wer eine bestehende Architektur systematisch verbessern möchte, dem empfehlen wir unser Advanced Level Training IMPROVE – Evolution und Verbesserung von Softwarearchitekturen.

Beschreibung

Bevor man sprichwörtlich das Rad neu erfindet und beispielsweise auch nur eine Zeile Code selbst schreibt, sollte man sich erst genau umschauen, ob das nicht bereits jemand vor einem getan hat. Jedes neu erfundene Rad muss getestet, gewartet und dokumentiert werden und das kann den Aufwand und somit die Kosten gewaltig in die Höhe treiben.

Auswirkungen

In diesem Fall ist das Problem vieler Softwareentwicklungsprojekten, dass die Software meist von Grund auf entwickelt wird. Top-Down Analyse und Design führen dabei oft zu neuen Architekturen und Individualsoftware, ohne dass ein Entwickler sich nach bereits vorhandenen Bibliotheken umschaut.

Ein weiteres Problem sind mangelnde Kommunikation und Technologietransfer zwischen einzelnen Entwicklungsteams oder Abteilungen.

Lösung

Bevor man mit der Entwicklung anfängt, sollte man sich erst erkundigen, ob es bereits eine Bibliothek gibt, welche dem gewünschten Ziel schon sehr nahe kommt. Denn „es gibt eigentlich nichts, was es nicht schon gibt!“

Endlich ist er da! Der zweite Beitrag in unserer Anti-Pattern Reihe, in der wir gängige Fehler aus der Softwaretechnik aufzeigen und Tipps geben, wie man sie zukünftig vermeidet beziehungsweise nachträglich behebt. Diesmal geht es etwas heißer zu, denn wir reden über Lava…genauer gesagt über Lava Flow!

Bei unserer 3-tägigen Grundausbildung für Softwarearchitekten, dem Foundation Level Training, bekommst du das nötige Know How, um von Anfang an gute und überschaubare Lösungsmuster zu entwickeln. Wer eine bestehende Architektur systematisch verbessern möchte, dem empfehlen wir unser Advanced Level Training IMPROVE – Evolution und Verbesserung von Softwarearchitekturen.

Beschreibung

Man spricht von einem Lava Flow, wenn sich im Laufe der Zeit immer mehr toter Code in einer Anwendung anhäuft, der eigentlich nicht mehr oder kaum noch gebraucht wird. Dieser tote Code zieht sich dann wie zähe Lava durch das System.

Auswirkungen

Dieser „tote Code“ steigert die Komplexität der Anwendung und kann dazu führen, dass irgendwann niemand mehr weiß, welche Codefragmente wie bereinigt werden können. Obendrein kann dieser Code wertvolle Ressourcen verschwenden und sich negativ auf die Performance auswirken.

Typische Merkmale eines Lava Flows sind undokumentierte,  „wichtig aussehende“ Methoden oder Klassen, deren eigentliche Funktion nicht ersichtlich sind, oder Stellen im Code mit Hinweisen wie z.B. „to be replaced“.

Lösung

Der beste Weg zur Vermeidung von Lava Flow ist eine klare Architektur, die vor Beginn der eigentlichen Implementierung entworfen und in einem Configuration Management Process gesichert werden sollte. Das Configuration Management gibt Informationen über verschiedene Versionen und verwendete Tools und dokumentiert Änderungen und deren Auswirkungen auf andere Programmteile.

Hilfreich können auch Tools zur Abhängigkeitsanalyse sein, wie z.B. JarAnalyzer oder JDepend, die statische Abhängigkeiten zwischen Java-Klassen ermitteln.

Du stehst vor einem Problem und hast das gute Gefühl, es durch deinen Erfahrungsschatz schnell und nachhaltig lösen zu können? Besser geht’s gar nicht!

Aber: „Für jedes Problem gibt es eine Lösung, die einfach, klar und falsch ist“, das wusste damals schon der Schriftsteller Henry Louis Mencken. Manchmal erkennt man leider erst hinterher, wenn der Ansatz bereits in die Tat umgesetzt wurde, dass das Lösungsmuster nicht die richtige Antwort liefern kann. Diese Form eines schlechten Lösungsmusters nennt man in der Softwareentwicklung Anti Pattern.

ITech Progress möchte mit Beiträgen rund um Anti Pattern gängige Fehler in der Softwareentwicklung aufzeigen und Tipps geben, wie man sie zukünftig vermeidet beziehungsweise nachträglich behebt. Bei unserer 3-tägigen Grundausbildung für Softwarearchitekten, dem Foundation Level Training, bekommst du das nötige Know How, um von Anfang an gute und überschaubare Lösungsmuster zu entwickeln. Wer eine bestehende Architektur systematisch verbessern möchte, dem empfehlen wir unser Advanced Level Training IMPROVE – Evolution und Verbesserung von Softwarearchitekturen.

Spaghetticode

Was zugegebenermaßen auf den ersten Blick wie eine italienische Geheimdienstmission klingt, ist der Titel des ersten Anti Patterns, den wir vorstellen möchten.

Beschreibung

Eine fortschreitende Erweiterung eines Systems erfordert auch eine kontinuierliche Anpassung der Anwendungsstruktur, da diese sonst mit der Zeit erodiert. Spaghetticode bezeichnet daher Software-Quellcode, der sehr komplizierte und undurchschaubare Strukturen zeigt und meist vom Programmierer selbst nach einigen Wochen nicht mehr verstanden wird.

Auswirkungen

Ein Spaghetticode kann unterschiedliche Ursachen haben. Meist tendieren unerfahrene Programmierer dazu Spaghetticodes zu erstellen, da es leichter ist Programmcodes anzufügen, statt den bestehenden zu verstehen und zu modifizieren. Eine häufige Erweiterung des Quellcodes, ohne die Durchführung eines Refactorings, kann ebenfalls zu einem Spaghetticode führen. Der Spaghetticode lässt sich aufgrund seiner wirren Struktur nur noch sehr schwer verändern, verbessern oder optimieren. Auch eine Wiederverwendung wird nahezu unmöglich.

Lösung

Am besten lässt sich dieses Problem durch inkrementelles Refactoring beheben. Refactoring befasst sich mit der Änderung von internen Strukturen eines Programms, ohne dabei dessen extern sichtbares funktionales Verhalten oder dessen bestehende Funktionalität zu ändern.

Ein weiterer Ansatz zur Vermeidung dieses Problems wäre der Einsatz von testgetriebener Softwareentwicklung (TDD). Hierbei werden erst die Softwaretests und anschließend der Programmcode erstellt, bis nach abschließendem Testdurchlauf alle Tests bestanden werden.

Der Entwickler formuliert seine Erwartungen vorab in den Code, doch dazu muss er diese Erwartungen kennen. Daher sollte der Implementierung die Modellierung zum besseren Verständnis der Zuständigkeiten vorausgehen.