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

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.

Read More

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

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.

Read More

Architecture without Architects

Architecture without Architects

Die Begriffe „Architektur“ und „Architekt“ hat die Softwareentwicklung aus der Baubranche adoptiert. Eine klug gewählte Softwarearchitektur, die sich auf bewährte Strukturmuster stützt und dadurch Flexibilität und Wartbarkeit bietet, ist unbestreitbar Teil eines erfolgreichen Softwareprojektes. Hier ist die Analogie des Begriffs „Architektur“ zwischen Bau- und Softwareindustrie richtig. Aber ist die begriffliche Gleichsetzung darüber hinaus nicht eher irreführend? Welche Rolle sollte ein Softwarearchitekt überhaupt innerhalb eines Softwareprojekts spielen? Ist der Softwarearchitekt vielleicht sogar überflüssig?

Read More

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.

Read More

Vaadin auf Grails: Kann das funktionieren?

Vaadin auf Grails: Kann das funktionieren?

Projektanfragen mit dem Wunsch, eine Rich Internet Application auf Basis des bekannten Vaadin-Frameworks zu entwickeln oder zu erweitern, sind für uns als Vaadin-zertifizierter Partner mittlerweile zur Selbstverständlichkeit geworden. Bei den meisten Kunden ist dabei bereits eine bestehende JEE-Architektur vorhanden, in welche das Vaadin-Framework eingebettet werden soll. Im Gegensatz dazu unterstützen wir aktuell einen Verlag bei einem agilen „Green-Field-Projekt“: einer vollkommenen Neuimplementierung einer Rich Internet Application mit Vaadin. Die Besonderheit dieses Projekts liegt darin, dass statt einer herkömmlichen JEE-Umgebung eine ebenfalls neu zu entwickelnde Grails-Architektur als Backend dienen soll.

Read More

Mit der Abrissbirne zu besseren Unittests - Erkenntnisse beim Kaffeetrinken mit Uncle Bob

Mit der Abrissbirne zu besseren Unittests - Erkenntnisse beim Kaffeetrinken mit Uncle Bob

Durch glückliche Umstände hatte ich vergangenes Jahr die Möglichkeit, an einem zweitägigen Workshop mit Robert C. Martin – besser bekannt als „Uncle Bob“ – teilzunehmen. Ich hatte zu dieser Zeit bereits einige Erfahrung mit testgetriebener Entwicklung gesammelt, sowohl in Coding Dojos als auch in der täglichen Projektarbeit. Die Arbeitsweise durch das Vorgehen nach TDD (test-driven development) hatte signifikant positive Auswirkungen auf die Qualität der Software, die wir bauten, und gab uns ein Gefühl für eventuelle Schwachstellen der Anwendungen.

Read More

Das Interface Segregation Principle - Nicht nur auf den Schnitt kommt es an

Das Interface Segregation Principle - Nicht nur auf den Schnitt kommt es an

In unserem heutigen SOLID-Beitrag geht es um das „Interface Segregation Principle“. Wie wir im Blog sehen werden, ist dabei weniger die Trennung nach Interfaces das Problem, als vielmehr die an manchen Stellen wieder benötigte, sinnvolle Zusammenführung von Funktionalitäten aus verschiedenen Interfaces eines Objekts.

Vorweg: Die Fachabteilung war ganz begeistert, dass wir neulich die Anforderung zur Aufnahme von nicht registrierten Kunden so schnell und sauber umsetzen konnten. Die ausführliche Geschichte und wie die Anwendung des Liskov Substitution Principle zu einer sauberen Lösung beigetragen hat, kann man im „L“-Blog unserer SOLID-Reihe nachlesen.

Allerdings hat diese Erweiterung den Einfallsreichtum angespornt. Die neue Vision: Zukünftig sollen weitere neue Kundentypen im System eingeführt werden können. Außerdem soll es möglich sein, bestehende Kunden in einen anderen Kundentyp zu wandeln ohne dazu den Kunden im System neu anlegen zu müssen. 

Read More

Das - Liskov Substitution Principle - LSP

Das - Liskov Substitution Principle - LSP

ubtypes must be substitutable for their base types. 

So, das „S“ und das „O“ der SOLID-Prinzipien haben unser Design hinsichtlich der Qualitätsmerkmale wie Wartbarkeit, Testbarkeit und Erweiterbarkeit bereits erheblich verbessert. Wir haben gesehen, dass es Sinn macht, einer Klasse möglichst nur eine Verantwortlichkeit zu übertragen (Single Responsibility Principle) und Programmcode offen für Erweiterungen, aber geschlossen für Änderungen zu implementieren (Open Closed Principle).

Read More

Das Open-Closed Principle (OCP)

Das Open-Closed Principle (OCP)

Software sollte lesbar, modular und wartbar sein. Leider entsteht im Laufe der Entwicklung, vor allem aber auch bei Weiterentwicklungen, immer wieder schlechtes Software-Design. Im schlimmsten Fall treten Programmfehler bei bereits längst getesteten Funktionalitäten auf. Die Beachtung der SOLID-Prinzipien objektorientierter Softwareentwicklung kann helfen, diese Fehler zu vermeiden und Programmcode wartbar zu halten. Insbesondere die Wartbarkeit ist von großer Bedeutung, da man selten Softwareentwicklung auf der grünen Wiese betreibt, sondern in den allermeisten Fällen auf vorhandenem Programmcode aufbaut.

Read More

Das Single Responsibility Principle (SRP)

Das Single Responsibility Principle (SRP)

There should never be more than one reason for a class to change.

Heute beginnen wir mit dem ersten SOLID–Prinzip: Eine Klasse sollte immer eine einzige Verantwortung haben, oder anders ausgedrückt: Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern (Single Responsibility Principle, SRP).

Das SRP wendet man an, um übersichtliche, leicht erweiterbare und einfach zu wartende Software zu konzipieren.

Read More

SOLID – ein Schritt zu mehr Professionalität in der Software-Branche

SOLID – ein Schritt zu mehr Professionalität in der Software-Branche

Schon vor vielen Jahren saß ich mal in einer Straßenbahn, wir standen an einer Haltestelle, es ging nicht weiter. Plötzlich hörten alle Motoren auf zu summen, alle Lichter gingen aus – und nach einiger Zeit wieder an. An der Anzeige über dem Fahrer blinkte die Firmware-Versionsanzeige auf. Was war passiert? Offenbar war die Straßenbahn „abgestürzt“ und der Fahrer hatte sie in seiner Not einfach neu gebootet.

Read More

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

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?

Read More

Behavior Driven Development

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.

Read More

Inversion of Control

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.

Read More

Automatisierte Tests über Weboberflächen

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.

Read More

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

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.

Read More

Legacy Code unter Kontrolle Folge 1 Vorstellung von JMockit

Legacy Code unter Kontrolle Folge 1 Vorstellung von JMockit

Bei meinem aktuellen Kunden setzen wir das Tool „JMockit“ so erfolgreich ein, dass es inzwischen einen wichtigen Platz in meiner „virtuellen Werkzeugkiste“ bekommen hat. Auch wenn sich die Entwickler in meinem Team größte Mühe gegeben haben, ordentlichen Code mit einem sauberen Design zu erstellen, so schlagen wir uns nun dennoch durch inzwischen weit über 1 Million Zeilen Java-Code, aus denen uns die Fehlentscheidungen der letzten 10 Jahre „entgegenmüffeln“. Wir kämpfen mit Legacy Code. Hier helfen uns Unit-Tests. Und JMockit spielt bei der Erstellung dieser Tests eine entscheidende Rolle.

 

Da JMockit noch recht neu und unbekannt ist, möchte ich es Ihnen hier in einer lockeren Folge von Blog-Einträgen näherbringen:

  • Folge 1: Vorstellung?
  • Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur sehr schwer zu erstellen wäre.
  • Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Remote-Service-Call und eine Schaltjahresregelung.
Read More