30. November 2015 | 4 min lesezeit

Der Weg in die Moderne – oder warum ein gutes Web-Framework allein die Welt nicht rettet

camel-993822_960_720 | CC0 Public Domain | https://pixabay.com/p-993822 | banksadamDienstag, 3. November 2015. 10.15 Uhr.

Die erste Session der WJAX 2015. Irgendwo in den Untiefen eines Konferenzhotels in München. Zeit etwas Neues zu lernen. Neue Impulse aufzunehmen. Die Energie der Community aufzusaugen. Und dann das: Ein Talk zu alten Web-Frameworks. Zur Migration eben dieser. Gibt es nichts Langweiligeres? Wen interessiert so etwas schon?

Nun – die Anzahl der Teilnehmer spricht eine andere Sprache. Und auch die Tatsache, dass keiner den Vortrag vorzeitig verlassen hat.

Zugegeben. Das Thema hat wenig Sex-Appeal. Altlastenbewältigung. Unzählige Restriktionen. Kein Freiraum. Kaum dokumentierte Anforderungen. Viele kleine Unbekannte, die sich oft als große Hürde erweisen. Seit 5 oder 10 Jahren gewachsen. Mannjahre oder Mannjahrzehnte an Entwicklung. In der Regel in einem geschäftskritischen Unternehmensbereich.

Was macht man damit? Wie kommt man davon weg? Und was sollte man beachten, damit einem in Zukunft nicht das Gleiche wiederfährt?

Innerhalb von 60 Minuten darauf eine Antwort zu liefern ist schwer. Zumals die Herausforderungen von Projekt zu Projekt sehr unterschiedlich sein können. Dennoch gibt es auf die Herausforderungen Antworten. Wichtige Antworten, die man unbedingt berücksichtigen sollte und die einmal mehr Erfahrungen benötigen. Unterschiedliche Blickwinkel. Risikoeinschätzungen. Erprobte Vorgehensmodelle.

Dem gegenüber steht das, was wir regelmäßig in derartigen Projekten erleben: Ganz am Anfang steht die Auswahl des zukünftigen Web-Frameworks. Aufgrund von Features und Funktionen und Antworten aus der Community. Selten wird dabei berücksichtigt, dass die (Enterprise Java) Entwickler-Community neben Log-Frameworks zu kaum einem anderen Thema so gut streiten kann wie zum Thema Web-Entwicklung. Gestritten wird dabei über die grundsätzliche Architektur, über die zu verwendenden Pattern, den Grad der (HTML-, CSS-, JavaScript-)Abstraktion und natürlich damit einhergehend über das zu verwendende Web-Framework.

Doch im Gegensatz zu Log-Frameworks, bei denen der Zustand zwischen vergleichsweise großer Einigkeit und unterschiedlicher Auffassung immer mal wieder hin- und herpendelt, ist im Bereich der Web-Entwicklung noch keine Ruhe eingekehrt. Eher im Gegenteil: Die Fronten zwischen den verschiedenen Lagern sind verfestigt, natürlich gibt es nur DAS eine Web-Framework. Und im Übrigen sind die anderen Ansätze von Grund auf mit Fehlern versehen.

Vor ungefähr 10 Jahren antwortete Rod Johnson auf die Frage „Warum sollten Web-Frameworks noch nicht standardisiert werden?“ mit „Weil wir das Problem der Web-Entwicklung noch nicht gelöst haben!“. Ein weiser Spruch, wie ich finde. Schaut man sich das derzeitige Momentum der Web-Entwicklung außerhalb der Enterprise Community an, so muss man leider attestieren, dass dies auch noch heute, 10 Jahre später, gilt. Und es ist zu vermuten, dass wir im Bereich der Web-Entwicklung auch die kommenden Jahre noch einiges an Momentum zu erwarten haben.

Kann daher „Der Weg in die Moderne“ mit der Auswahl des Web-Frameworks beginnen? Eher nicht.

Vielmehr muss, und das zeigen die Erfahrungen, der erste Blick auf die Assets einer bestehenden Web-Anwendung erfolgen. Neben dem Asset No.1 – dem vorhandenen Entwicklerteam mit meist langjähriger fachlicher Erfahrung – finden sich die wichtigsten Assets direkt im Code:

  • Core-Widgets, die über die gesamte Anwendung hinweg verwendet werden
  • Das Formular-Layout einzelner Views (gerade bei komplexen Datenerfassungsmasken)
  • Die Art der Validierung und die Validierungsregeln
  • Die UI-nahe Logik
  • Der allgemeine Screen-Flow

Dummerweise sind diese Assets gerade bei älteren Web-Projekten nicht direkt an einer Stelle im Code zu finden, oder liegen in einer Form vor, die weder eine technische (in Form vom Code) noch eine fachliche (in Form von Anforderungen) Wiederverwendung zulässt.

Der „Weg in die Moderne“ kann deshalb nur über die Berücksichtigung und die Bewertung dieser Assets erfolgen und führt am Ende zur Auswahl eines Web-Frameworks. Nicht umgekehrt. Dabei spielen Fragen wie „Was kann wiederverwendet werden?“, „Was muss so erhalten bleiben?“ bzw. „Wo ist eine Neuentwicklung notwendig oder vertretbar?“ eine wichtige Rolle. Doch die wichtigste Frage auf diesem Weg ist die Frage nach den Auswirkungen für das bestehende Team: „Wird mein Team, also meine Fachexperten, diesen Weg mitgehen können?“

So kommt es nicht von ungefähr, das die Empfehlungen für den „Weg in die Moderne“ oftmals gleichartige Vorgehensmodelle, aber unterschiedliche Web-Frameworks zur Folge haben. Zwei Empfehlungen lassen sich für Web-Migrationen in jedem Fall aussprechen:

  • Unabhängig davon, ob Anforderungen gut oder schlecht dokumentiert sind, ist das bestehende Team das wichtigste Asset, dass es durch die Auswahl eines Web-Frameworks nicht zu verlieren gilt. Das modernste und beste Web-Framework der Welt ist nur so gut, wie es von dem bestehenden Team beherrscht werden kann. Dies zeigen üblicherweise Probleme, die durch einen Wechsel von einem Action- zu einem Component-Based Framework entstehen. Aber auch die Herausforderungen für Teams, von serverseitiger zu clientseitiger Entwicklung zu wechseln. Stichwort JavaScript und CSS-Frameworks.
  • Es ist davon auszugehen, dass Web-Entwicklung in fünf oder acht Jahren gänzlich anders aussieht als heute. Wir müssen damit leben, dass Code, der heute mit modernsten Ansätzen der Web-Entwicklung realisiert wird, in dieser Zeitspanne komplett veraltet sein wird und uns dort hinführt, wo wir mit dem seinerzeit absolut modernen Web-Framework Struts (oder Vergleichbare) mittlerweile gelandet sind. Dabei ist es nicht schlimm, dass diese Entwicklung stattgefunden hat. Schade ist vielmehr, dass all die Energie, die in den Code geflossen ist, der unsere Web-Assets ausmacht, oftmals verloren ist. Und das gilt es bitte für die Zukunft zu verhindern.
    Das kann mit dem Web-Framework XYZ nicht passieren? Sicher? Ich empfehle dazu einen Blick auf die Folien 39ff. meiner Präsentation.

Am 3.11.2015, kurz nach 11.15 Uhr, habe ich formuliert, dass die Migration von Web-Anwendungen der ersten Generation eines der komplizierten Aufgabenstellungen ist, die Enterprise Java uns bisher hinterlassen hat. Doch mit dem Austausch der Web-Technologie, was allein schon kompliziert genug ist, ist es nicht getan. Arbeitet man weiter wie bisher, vielleicht mit dem falschen Framework für das bestehende Team, ist man nach der Migration näher am Abgrund als zuvor.

Keine guten Aussichten. Aber mit den entsprechenden Erfahrungen beherrschbar.


Keine Kommentare

Kontakt

OPEN KNOWLEDGE GmbH

Standort Oldenburg:
Poststraße 1, 26122 Oldenburg

Standort Essen:
II. Hagen 7, 45127 Essen