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.

IT-Teams sind schon ein Volk für sich, und das ist durchaus positiv gemeint. Die ITler bilden oft einen „fachlichen Mikrokosmos“ im Unternehmen und bleiben gerne unter sich. Das heißt aber noch lange nicht, dass Entwickler, Architekten, Scrum Master, Tester, Deployment Manager und Projekt­manager auch nur ansatzweise eine Sprache sprechen – von Abteilungsleitung und Management einmal ganz abgesehen. Unterschiedliche Ausbildungswege und fachliche Schwerpunkte, aber auch individuelle Unternehmens- und Projekterfahrungen führen in der Regel dazu, dass Fachtermini nicht durchgängig bekannt sind oder von Mitarbeiter zu Mitarbeiter anders verstanden werden. Die resultierenden Missverständnisse können gravierende Auswirkungen auf Effizienz und Projekterfolg haben und im Zweifel eine Menge Geld kosten. Aber was tun?

Ein Lösungsansatz, auf den immer mehr Unternehmen ihr Augenmerk richten, findet sich in der teamweiten Grundlagen­schulung. Der Foundation Level des Weiterbildungsprogramms zum Certified Professional for Software Architecture (CPSA-F) nach iSAQB-Standard hat sich dafür bestens bewährt. In einem dreitägigen Intensivtraining erhalten die Teilnehmer eine umfassende Einführung in die relevanten Definitionen, Methoden und Techniken der Softwarearchitektur und entwickeln so eine gemeinsame Wissensbasis und Sichtweise für die Softwareprojekte, kurzum: eine universell verfügbare Fachsprache (Ubiquitous Language). Die architektonische Perspektive hat sich dabei als sinnvoll erwiesen, da die Teilnehmer die Softwareentwicklung stärker als Gesamtkonzept kennen- und betrachten lernen als durch den fokussierten Blick des Entwicklers. Als willkommenen Nebeneffekt können die Teilnehmer mit einer Abschlussprüfung das anerkannte iSAQB-Zertifikat für den CPSA Foundation Level erlangen.

Für Unternehmen mit limitiertem Fortbildungsbudget bilden Inhouse-Trainings eine kostengünstige Alternative zu den offenen Trainings, wie sie an vielen Standorten in Deutschland regelmäßig stattfinden. Bereits ab einer Größenordnung von 5-6 Teilnehmern können sich Schulungen im eigenen Haus rechnen. Bei einer Auslastung mit 10-12 Personen je Training beträgt das Einsparpotenzial sogar bis zu 50%. Aber nicht nur aus Kostengründen sind Inhouse-Trainings interessant: Wenn ein Zuschnitt der Trainingsinhalte auf eigene Projektanforderungen notwendig ist, gibt es dafür bei Inhouse-Trainings zumeist einen gewissen Spielraum. Bei offenen Schulungen bleiben individuelle Anliegen für gewöhnlich auf die eine oder andere Zwischenfrage begrenzt. So ist es kein Wunder, wenn Inhouse-Trainings in den vergangenen Jahren einen regelrechten Boom erleben.

Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Nähere Informationen der ITech Academy:

iSAQB Schulungen (Übersicht)

iSAQB Foundation Level (Training & Termine)

Inhouse Trainings (Information & Anfragen)