Publikationen

Viele Rendering Patterns wurden bereits in den letzten beiden Artikeln betrachtet. Wir konnten die Entwicklung verfolgen, wie Inhalte zuerst statisch sowie serverseitig gerendert wurden, dann immer mehr Aufgaben auf den Client verlagert wurden, bevor der Trend wieder zurück zum Server ging. Die Kunst besteht heute darin, in diesem Spektrum den optimalen Bereich, den sogenannten Sweet Spot zu finden.

Nachdem im ersten Teil die Grundlagen für ein besseres Verständnis davongelegt wurden, wie Inhalte im Web geladen und gerendert werden, wenden wir uns nun komplexeren Ansätzen zu.

SSG, SSR, CSR, ISR, Prerendering, Hydration, Streaming, Resumability. Einige dieser
Begrifflichkeiten begegnen einem Entwickler, wenn er oder sie sich mit der Frage
beschäftigt, wie Inhalte im Web geladen und dargestellt werden können. Vielen
ist dabei nicht klar, was sich dahinter verbirgt und welche Stärken bzw. Schwächen
die Patterns haben. Bringen wir Licht ins Dunkel.

Wer schon in einem Entwicklungsteam gearbeitet hat, der kennt das bestimmt: Schattenboxen mit Problemen, die konkrete Schmerzen bereiten, aber deren Ursache schwer greifbar ist. “Ich komm zu nix!”, “Warum wurde dieser Service schon seit Jahren nicht geupdatet?”, “Bei dem Thema sind wir jetzt der Flaschenhals”, “Diesen Sprint haben wir wieder nicht viel geschafft, es waren zu viele Ablenkungen”. Die schwer greifbare Ursache ist nicht selten die zu hohe kognitive Last – Cognitive Load – des Teams. Aber was ist das genau? Woher kommt das? Und was macht man dagegen? Das wollen wir uns in diesem Artikel mal genauer anschauen.

Heutige Softwareentwicklung wendet häufig Techniken des modernen Domain-Driven Design an. In dessen Kern gilt es, mit geeigneten Kommunikationsmitteln abgeschlossene Kontexte zu finden und in Software zu gießen (Achtung: Conway‘s Law). Die soziologische Systemtheorie nach Luhmann fokussiert auf Kommunikation und nimmt in ihrem Kern die Unmöglichkeit unabhängigen Beobachtens an. Zusammengenommen kann dies ein besseres Verständnis für die Anforderungsfindung und das Zusammenstellen und -arbeiten von Teams liefern.

Javamagazin Heft 2|21: Puh, endlich geschafft. Die Artikelserie geht dem Ende zu. Diese Menge Code zu einem anständigen Modulithen zu formen, war ganz schön anstrengend. Zum Glück ist er jetzt fertig, alle Arbeit ist getan! Wie? Weiterentwicklung? Wartung und Betrieb? Neue Anforderungen? Das Team skalieren? Technische Schulden? Aber das Ding ist doch ganz neu! Warum müssen wir da schon wieder ran? Tja, machste nix. Oder doch?

Javamagazin Heft 1|21: So manche Codebase macht nur auf den ersten Blick einen aufgeräumten Eindruck. Schön in Packages sortierter Code ohne Abhängigkeitsmanagement ist wie ein „auf-geräumtes“ Kinderzimmer, bei dem einem die Lawine entgegenkommt, wenn man es wagt, die Schranktür aufzumachen. Um zu verhindern, dass Abhängigkeitszyklen und wuchernde Queraufrufe den Code zu einem „Big Ball of Mud“ machen, gilt es, höllisch aufzupassen.

Javamagazin Heft 12|20: „Wir haben diesen Legacy-Monolithen, den wollen wir in Microservices aufbrechen“. So einen Satz hört man als Berater in der Softwarebranche oft. Auf die Frage „Warum“ erhält man oft die Antwort „Modularisierung“. Denn es herrscht die weitverbreitete Ansicht, dass Monolithen grundsätzlich aus schlecht strukturiertem Legacy-Code bestehen und sich Monolithen und Modularisierung gegenseitig ausschließen. Dass dem nicht so ist, zeigt die Architekturform der Modulithen.

Informatik Aktuell: In seiner Arbeit von 1968 formulierte Melvin Conway die nach ihm benannte (empirische) Gesetzmäßigkeit: “Jede Organisation, die im weitesten Sinne ein System entwirft, wird ein Design erzeugen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.” [1] Diese Gesetzmäßigkeit – als Conways Law bekannt – kann auf unterschiedliche Arten und Weisen interpretiert werden (EuroPLoP). Seit einiger Zeit ist auch der Begriff des inversen Conway-Manövers (Inverse Conway Maneuver) bekannt, das sich als Werkzeug versteht, eine Organisation so zu formen, dass das Ergebnis einem formulierten Architekturwunsch entspricht: “Idealerweise sind die technologische Struktur und die Geschäftsstruktur zueinander isomorph.” [2] Dieser von Conways Law konstatierte Isomorphismus, der eine strenge formale Gleichheit zwischen System(design) und der Kommunikationsstruktur im Unternehmen beschreibt, hat also zwei Richtungen. D.h. Änderungen in der Unternehmenskommunikation beeinflussen notwendig die Struktur des Softwareproduktes, und umgekehrt beeinflusst (und steuert) eine Software notwendig die Prozesse, die sie abbildet.