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, wenn wir reden über Lava…genauer gesagt üvber 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.

ITech Night School über Blockchain (2/2)

ITech Night School über Blockchain (2/2)

Alle zwei Wochen findet unsere interne Weiterbildungsmaßnahme mit dem Namen Night School, von den Kollegen für die Kollegen, in unseren Räumlichkeiten in Nürnberg statt.

Bei der vorletzten Night School beschäftigten sich die Kollegen bereits mit einer allgemeinen Einführung zur Architektur und der Geschichte der Blockchain-Technologie. Hier klicken, um den Beitrag zur ersten Blockchain-Night School zu lesen.

Bei dem zweiten Termin tauchten unsere Kolleginnen und Kollegen anhand einer Praxisübung dann noch tiefer in die Materie ein. Sie starteten eine Blockchain in Java zu implementieren, um ein besseres Bild von der Technologie zu bekommen. Dabei haben sie Mob Programming angewendet. Heißt: das gesamte Team hat, ganz im Sinne der Night School, gemeinsam und zeitgleich zur Entwicklung der Blockchain an einem PC gesessen. Schließlich sehen vier Augen mehr als zwei und mehrere dutzende Augen natürlich umso mehr! Die Fehlerquote fällt also deutlich geringer aus und die Qualität des Codes steigt.

Immer wieder liest man, dass der Einstieg in die Blockchain Technologie aufgrund der komplexen Algorithmen ein schwieriger Gang ist und einige Tage an intensiver Einarbeitung benötigen…und was sollen wir sagen, die Kolleginnen und Kollegen können das nur bestätigen! Als Fazit würden sie sagen, dass Blockchain durchaus keine Rocket Science ist, aber unter Zeitdruck eher Verzweiflung als Freude aufkommt.

Wir verraten euch schon mal, dass es bei der nächsten Night School den zweiten Teil unserer Reihe über Künstliche Intelligenz gibt (Hier klicken zum ersten Teil). Unser Team tauscht sich dann über die Theorie von Machine Learning aus.

ITech Night School über Künstliche Intelligenz

ITech Night School über Künstliche Intelligenz

In dieser Woche fand wieder eine Night School, die interne Weiterbildungsmaßnahme von Kollegen für Kollegen, statt. An unserem Standort in Nürnberg haben sich die Kollegen bei leckerer Pizza und anderen Snacks mit der grundlegenden Frage „Was ist K.I.?“ beschäftigt. Es war die erste von insgesamt drei Night Schools zu künstlicher Intelligenz und deren Einfluss auf unser Leben.

Dabei ging es weniger darum, dass künstliche Intelligenz irgendwann die Weltherrschaft übernehmen könnte, sondern erst mal um die Fähigkeit von Geräten und Software logisch zu denken, zu lernen und somit Probleme zu lösen.

Bereits vor Jahren konnte man Schlagzeilen wie „Künstliche Intelligenz beendet menschliche Dominanz“ lesen als es darum ging, dass die Google-KI innerhalb von vier Stunden (ohne Vorkenntnisse) zum unschlagbaren Schach-Genie wurde.

Während es sich hier um analytische Fähigkeiten handelt redet man auch immer mehr von menschengleicher KI. Diese KI auf Human Level ist Zukunftsmusik und wird als „starke KI“ eingestuft. Davon sind wir allerdings noch entfernt und können uns zum aktuellen Stand ausschließlich „schwacher KI“ in Form von Alltagssystemen wie Alexa bedienen. Am Ende dieser Entwicklung würde eine „Superintelligenz“ stehen, die der Menschlichen Intelligenz in vielem oder sogar allem überlegen ist.

Die Kollegen beleuchteten also die Entwicklung der KI von den Anfängen bis heute und zeigten anhand des Periodensystems der KI welche Bausteine zu einem KI-System gehören. In den nächsten Night Schools sehen sich die Kollegen an, wie KI uns in Science Fiction und Kinofilmen begegnet und was KI heute wirklich schon kann. Am Ende der drei Night Schools gibt es eine Übung um herauszufinden, wie die Welt im Jahre 2050 aussehen könnte.

Es bleibt also spannend, was bei den nächsten Terminen noch passiert. Wir werden euch berichten!

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.

ITech Night School über Blockchain (1/2)

ITech Night School über Blockchain (1/2)

“Alle zwei Wochen findet unsere interne Weiterbildungsmaßnahme mit dem Namen Nightschool “von den Kollegen für die Kollegen“ in unseren Räumlichkeiten in Nürnberg statt. Die Nightschool am 15.05.19 lief unter dem Titel „Blockchain – Grundlagen und Architektur“. Neben einer allgemeinen Einführung nur Entstehung und Geschichte der Technologie, behandelten wir die Anforderungen und den Aufbau der Blockchain. Zunächst erhielten die Teilnehmer eine explizite Definition und lernten, wie das Verkettungsprinzip einer Blockchain funktioniert und was es so besonders macht. Danach wurden die Anforderungen der dezentralen Buchführung erläutert, sowie die verschiedenen Konsensverfahren, mit denen neue Blöcke geschaffen und an die bereits vorhandene Blockchain gehängt werden können. Hierbei wurde auch das populärste Konsensverfahren „Proof of work“ mit seinen Transaktionsregeln thematisiert.

Das berühmteste Anwendungsbeispiel ist wohl die Kryptowährung “Bitcoin”, welche von unseren Kollegen näher unter die Lupe genommen wurde. Zudem wurden auch Nachteile der Blockchain aufgeführt und die Frage geklärt, wie man mit diesen am besten umgeht. Zuletzt fand eine Bewertung der Blockchain in Bezug auf die Zukunft und den sozioökonomischen Kontext statt.

Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Der Abnahmetermin für die Software steht bevor und das Review der Softwarearchitekturen sorgt für schlaflose Nächte. Eine Architekturbewertung soll durchgeführt werden um die Stärken und Schwächen der Softwarearchitektur zu ermitteln. Wurden die relevanten Qualitätsmerkmale erfüllt und alle Ziele erreicht?

Grundlegend geht es bei der Architekturbewertung darum, herauszufinden, ob eine Softwarearchitektur die in sie gesetzten Erwartungen erfüllt oder nicht. Was sind die Stärken und Schwächen einer Architektur und welche Risiken und Probleme ergeben sich daraus?

Als Vergleich zur Softwarearchitekturbewertung nehmen wir einmal die Bewertung von sportlichen Leistungen. Genau wie bei der Softwarearchitektur lassen sich auch sportlichen Leistungen je nach Disziplin mehr oder weniger gut beurteilen. Wer läuft schneller? Wer springt höher? Wer wirft weiter? Wer schießt mehr Tore?  Diese Fragen sind noch einfach zu beantworten. In der Softwarearchitektur sind die Fragen natürlich ein wenig anders: Wie viele gefundene Fehler gibt es pro Paket? Wie hoch ist der Resscourcenverbrauch? Wie viel Zeit wird für die Verarbeitung bestimmter Funktionen oder Anwendungsfälle benötigt?

Doch nicht alle Fragen sind immer so leicht zu beantworten. Die Bewertung von Turniertänzern oder Eiskunstläufern ist schon etwas komplizierter und lässt sich nicht nach einfachen Zahlen bemessen, sondern funktioniert nach einem komplizierten Schema. Die Qualität entscheidet!

Wie ist das nun in der Softwarearchitektur? Gibt es hier sowas wie Messlatten und Schiedsrichter? Wie sieht hier das Ergebnis aus? Im Sport ist das klar: Der Gewinner bekommt die Goldmedaille.

  • Wie zuverlässig läuft das System?
  • Wie sicher ist das System?
  • Kann die Software ihr Leistungsniveau unter festgesetzten Bedingungen über einen bestimmten Zeitraum aufrechterhalten?
  • Wie sparsam ist die Software zur Lösung eines festgelegten Problems bezüglich der Ressourcen, Zeitverhalten bei Anfragen und Bearbeitungen sowie Speicherplatz?
  • Wie hoch ist der Aufwand zur Fehlerbeseitigung, zur Umsetzung von Verbesserungen oder zur Anpassung an Umgebungsveränderungen?
  • Ist die Software auch auf anderen Systemen (Hard- und Software) einsetzbar?

In der Softwarearchitektur gibt es verschiedene Methoden und Werkzeuge, die zu unterschiedlichen Zeitpunkten eingesetzt werden können. Bei der Bewertung einer Architektur gibt es jedoch zwei Ansätze: der qualitative Ansatz und der quantitative Ansatz.

Qualitativer Ansatz zur Architekturbewertung

Der qualitative Ansatz ermöglicht eine Bewertung nach Beschaffenheit oder Güte der Softwarearchitektur und hilft frühzeitig Risiken zu identifizieren, die die Erreichung der Qualitätsziele gefährden können. Ein Qualitätsmodell (wie z.B. ISO 25010) kann verwendet werden. Das ISO Modell definiert acht Qualitätsmerkmale: Benutzbarkeit, Effizienz, Funktionale Eignung, Kompatibilität, Sicherheit, Übertragbarkeit, , Wartbarkeit und Zuverlässigkeit.

Die qualitative Bewertung sollte jedoch regelmäßig und so früh wie möglich stattfinden. Eine der führenden Methoden im Bereich der Softwarearchitekturbewertung ist ATAM. ATAM seht für Architecture Tradeoff Analysis Method und bezeichnet eine Szenario-basierte Methode zur Bestimmung der Stärken, Schwächen und den getroffenen Kompromissen einer Softwarearchitektur. Ein ATAM-Workshop dauert in der Regel 3 – 4 Tage und wird gemeinsam mit den Stakeholdern durchgeführt.

Quantitativer Ansatz zur Architekturbewertung

Der quantitative Ansatz ist eine Bewertung der Artefakte in Zahlen und kann helfen, kritische Teile innerhalb von Systemen zu identifizieren. Im Gegensatz zur qualitativen Bewertung liefert sie keine Aussage über die Funktionsfähigkeit der Software. Zur Bewertung wird eine Reihe von Messungen und Metriken verwendet, wie beispielsweise die Anzahl der geänderten Anforderungen pro Zeiteinheit, die Anzahl der Testfälle, die Anzahl der gefundenen Fehler pro Paket, die Anzahl der neuen Codezeilen oder die Zyklomatische Komplexität. Der Vorteil ist, dass die Messungen automatisierbar sind und leicht wiederholt werden können. Es besteht jedoch auch die Gefahr von Missdeutungen, da ein fachlicher und technischer Kontext benötigt wird, um vergleichbar zu sein. Gesammelte Daten aus Vergleichsprojekten können hierbei hilfreich sein.

Insgesamt gesehen ist die Architekturbewertung ein wichtiges Hilfsmittel zur Bestimmung der Qualität einer Software bei der es aber weniger darum geht die Architektur zu benoten, sondern eher mehr Durchblick zu bekommen.

Architekturbewertung nach ISAQB AWERT

Die iSAQB-zertifizierte Weiterbildung Architekturbewertung vermittelt den Schulungsteilnehmern das notwendige Wissen und die Fähigkeiten, um Softwarearchitekturen bewerten zu können. Ziel ist die Beantwortung der Frage: Wie findet man heraus, ob eine Architektur die Erwartungen erfüllt?

Weiterführende Links:

Training “iSAQB Architekturbewertung (AWERT)”