Anti Pattern: Lava Flow

Anti Pattern: Lava Flow

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.

Anti Pattern: Spaghetticode

Anti Pattern: Spaghetticode

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.

Girls’ Day

Girls’ Day

Unser erster Girls‘ Day ist nun vorbei, bei dem wir 9 Teilnehmerinnen einen spannenden Einblick in die Welt der Softwarearchitekten ermöglichen konnten. Zu Beginn stellten wir uns als Arbeitgeber vor. Danach wurden den Mädchen einige Grundlagen der Softwarearchitektur erläutert, die sie später in Gruppenarbeit in praktischen Programmierübungen auf der Website „Scratch“ ausprobieren konnten. Im Anschluss wurde das Erarbeitete dann in einer Präsentation vorgestellt. Darüber hinaus durfte natürlich auch ein Rundgang mit expliziter Einführung in unser Unternehmen nicht fehlen, bei der sich auch die Geschäftsführerin vorstellte und schildern durfte, wie sie es schaffte, sich in einem männerdominierten Berufsfeld durchsetzen zu können. Auch die von uns organisierten Snacks und „la Pizza“ als Mittagessen sind bei den Mädchen sehr gut angekommen:). Wir bedanken uns für den schönen und lehrreichen Tag und hoffen, viele junge Mädchen für den Beruf “Softwarearchitektin” begeistert zu haben.

Hier einige Feedbacks der Mädchen:

„Es hat sehr viel Spaß gemacht, den Girls’ Day in eurer Firma zu verbringen!”

„Mir hat es sehr viel Freude bereitet, den Tag als „kleine Programmiererin“ oder Softwarearchitektin zu gestalten. Alle ihre Mitarbeiter sind super freundlich und man hatte viel Spaß, hier zu sein.“

„Der Tag in eurer Firma war echt cool und gelassen. Das ganze Essen war auch lecker. Die Räumlichkeiten der Firma sind auch richtig modern gestaltet.“

„Ich danke ihnen für das Essen und Trinken und hoffe ihr macht weiterhin beim Girls’ Day mit.“

„Ich fand sehr gut, dass wir anfängergerecht ans Programmieren herangeführt wurden…“

„Nehmen Sie unbedingt noch an weiteren Girls’ Days teil, damit auch andere Mädchen die Gelegenheit haben in das Programmieren und in Ihre Firma Einblick zu erhalten“…

„Ich habe Interesse an dem Beruf gefunden. Die Führung durch die Räume war gut, weil die Räume wirklich schön gestaltet sind. Für das nächste Mal würde ich sagen, dass sie genauso weitermachen sollen.“

Night School – Weiterbildung von Kollegen für Kollegen

Night School – Weiterbildung von Kollegen für Kollegen

Alle zwei Wochen findet unsere interne Weiterbildungsmaßnahme „von den Kollegen für die Kollegen“ in unseren Räumlichkeiten in Nürnberg statt. Die Maßnahme, in welcher wir laufend unsere Mitarbeiter weiterbilden nennen wir „Night School“.

 

 

Die erste Nightschool 2019 lief unter dem Titel „Von der Anforderung zum UML-Modell“ und hatte dementsprechend das Thema Objektorientierung, UML und Anforderungsanalyse. 

 

Zunächst wurde beschrieben welche Eigenschaften objektorientierte Systeme ausmachen.
Danach wurde die Unified Modeling Language als grafische Beschreibungssprache zur Objektorientierten Analyse (OOA) eingeführt.
Die UML-Diagrammtypen Use-Case Diagramm, Aktivitätsdiagramm, Sequenzdiagramm, Klassendiagramm, State-Machine und Deployment-Diagramm wurden anhand von Beispielen vorgestellt.
Danach wurde eine Analysemethode vorgestellt anhand von Textanalyse Use-Cases, Aktivitätsdiagramme, State-Machines um schliesslich ein Klassendiagramm zu ermitteln.

Im Praxisteil analysierten die Teilnehmer in kleinen Teams zu 3-4 Personen wie man aus der textuellen Beschreibung des Spiels “Dame” mittels Textanalyse die UML-Diagramme ermittelt.

 

Die zweite Nightschool hatte das Thema Dokumentationsmöglichkeiten in agilen Projekten.  Zunächst wurde erläutert warum man dokumentieren soll und was die Vorteile einer guten und aktuellen Dokumentation sind. 

Dann wurde auf die verschiedenen Dokumentationstypen:  Projektdokumentation, Systemdokumentation und Prozessdokumentation eingegangen und warum es im agilen Umfeld nicht zwingend geboten ist Dokumentation einzusetzen.

Als Lösungsmöglichkeiten wurden Wiki als Master, der Docs-as-Code Ansatz und Lean Dokumentation vorgestellt. Im Praxisteil bekamen Zweierteams ein Use-Case zugeordnet, dessen Ablauf sie mit Hilfe von Klebebändern, großen Post-ITs und Malstiften an die Wand zu basteln und ihre Lösung mit den anderen Teams zu diskutieren.

Die Ubiquitous Language der Softwareentwicklung

Die Ubiquitous Language der Softwareentwicklung

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)