Tag: software architecture

Micro-Frontends: Die bessere Art User Interfaces zu implementieren? Teil #2

Im ersten Teil unserer Blogserie hatten wir den grundsätzlichen Nutzen des Einsatzes von Mirco-Frontends erläutert und die Vor- und Nachteile dieses Ansatzes abgewogen. Darüber hinaus waren wir auf die Herausforderungen eingegangen, die gemeistert werden müssen, um Mirco-Frontends erfolgreich einzusetzen und hatten als ersten Ansatz iFrames vorgestellt. In diesem Teil wollen wir nun drei weitere Ansätze besprechen: Multi-Page, Varnish Cache & Esi Lang sowie „Blackbox“ React components.

Micro-Frontends – Die bessere Art User Interfaces zu implementieren?

Die Funktionalität von Anwendungen wächst stetig und die gemeinsame Arbeit mehrerer Teams an einer gemeinsamen Codebasis ist in einigen Fällen nicht mehr praktikabel. Am besten ist es, wenn die Teams weitestgehend unabhängig voneinander arbeiten können und die fachliche Komplexität nicht zu hoch ist. Einige ahnen jetzt schon auf welches Buzzword hier abgezielt wird – Micro Services. Micro-Services sind momentan vor allem im Backend ein Thema. Wenn wir den Ansatz in das Frontend portieren wird daraus Micro-Frontends.

Software Architecture Summit 2016

Vom 16. – 18.03.2016 fand der Software Architecture Summit in München statt. An diesem Informations- und Trainingsevent für Softwarearchitekten, Senior-Entwickler und IT-Projektleiter nahm ich, Steffen Kleeberg, in diesem Jahr teil. In halb- bzw. ganztägigen Workshops gingen deutschsprachige und internationale Architektur-Experten tief ins Detail, sodass die Entscheidung, welche Vorträge ich besuchen würde, nicht leichtfiel.

Beideskönner. Wie das Gemini Blueprint Projekt Spring und OSGi miteinander sprechen lässt

Es könnte doch eigentlich alles so schön sein.

In der Theorie lernen wir von Programmierers Kindesalter an, wie moderne Architekturen aussehen, wie moderne objekt- und vor allem service-orientierte Konzepte funktionieren. Dass über Bausteingrenzen hinweg munter und verteilt kommuniziert wird, dass ein hoher Wiederverwendungswert einzelner Bausteine zum schnellen voranschreiten in der Projekt-Entwicklung führt und dass wir das Rad nur noch selten neu erfinden müssen. Modernes Programmieren gleicht mehr dem zusammensetzen von Bausteinen zur Entwicklung einer Lösung statt dem klassischen Entwickeln von Bausteinen selbst.

Als Spring noch das allgemein gängige Handwerkszeug war, um Bausteine von Software Architekturen elegant zu entkoppeln, gab es keine Sprachbarriere. Spring-Beans konnten sich wunderbar untereinander und mit Hibernate unterhalten, mit gut zusammengestellten Konfigurationsdateien waren schnell große Projekte aufgesetzt und zusammengepuzzelt.

Nun stellt seit einigen Jahren OSGi die spring’sche Vormachtstellung in Frage bzw. greift unterstützend und maßgebend in neuere Systemarchitekturen ein. Daher scheint es nur folgerichtig, eine verständliche Antwort auf die Frage „Was ist OSGi?“ zu suchen und zu untersuchen inwiefern OSGi mit Spring kombiniert werden kann.

Also, was ist das nun, OSGi und warum gilt es überhaupt darüber nachzudenken zukünftige Systeme in ein OSGi Umfeld zu integrieren, wenn Spring doch unsere Probleme bisher ganz vorzüglich lösen konnte?

Behavior Driven Development

n Projekten kommt es immer wieder vor, daß Kunden und Business Analysten bei der Präsentation der Ergebnisse einer Softwareentwicklung ihre Anforderungen nicht umgesetzt sehen. Gründe dafür können z.B. unspezifische Anforderungen, fehlende Beispielfälle und Mißverständnisse bei der Interpretation der Anforderungen sein. Softwareentwickler leiten aus der sprachlichen Spezifikation Testfälle in Programmcode ab, die von technikfernen Projektbeteiligten nur schwer verstanden und geprüft werden können. Wie kann es ermöglicht werden, diese automatischen Tests lesbarer zu gestalten, so daß sie durch Business Analysten und Kunden geschrieben und abgenommen werden können? Bei der Suche nach Lösungen bin ich auf “Behavior Driven Development” gestoßen.

Inversion of Control

Vergleichbar mit der Konstruktion eines Wolkenkratzers, müssen bei der Erstellung einer Software Architektur-Richtlinien definiert und berücksichtigt werden. Wird dies nicht befolgt, stürzt die Konstruktion über kurz oder lang ein.
Inversion of Control gibt dem Entwickler ein effektives Tool an die Hand, um Software auf Klassenebene so solide zu bauen, dass auch bei größeren Umbaumaßnahmen oder langjähriger Weiterentwicklung die Architekturaspekte Erweiterbarkeit, Wiederverwendbarkeit, Testbarkeit nicht in Mitleidenschaft geraten.

Automatisierte Tests über Weboberflächen

Fast jeder kennt das Problem. Man implementiert neue Funktionalität, führt eventuell noch paar Code-Optimierungen durch und lässt anschließend Unit-Tests laufen. Obwohl alle Tests erfolgreich sind, ist man trotzdem nicht immer sicher, ob eigene Änderungen keine Seiteneffekte verursacht haben, die erst beim manuellen Testen der Applikation über die Oberfläche ersichtlich werden. Ganz schlimm wird es, wenn diese Fehler ganz übersehen werden. Meistens ist es nicht der Fall. Doch wer sicher sein will, sollte sich über Testautomatisierung der Benutzeroberflächen (GUI-Testing) Gedanken machen.

Legacy Code unter Kontrolle – Folge 3, JMockit für Fortgeschrittene

m ersten Blog-Eintrag dieser kleinen Serie habe ich erzählt, warum JMockit eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung zu testen. Im nächsten Eintrag habe ich das wichtigste API von JMockit, das Expectations-API vorgestellt. Als Abschluss zeige ich an zwei konkreten Beispielen aus der Praxis, wie JMockit einem auch in schwierigen Fällen einen Unit-Test möglich macht.

Hier nochmal der Überblick über die ganze Serie:
•    Folge 1: Vorstellung von JMockit
•    Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur schwer zu erstellen wäre.
•    Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Schaltjahresproblem und ein Singleton-Factory-Lindwurm.