Category

Artikel

Experten-Check auf JAXenter: Was ist schöner Code?

By | Artikel, Publikationen | No Comments
„Was ist guter Code für Software-Architekten?“ (Teil 1 der Themenserie)

JAXenter Logo

Teil 1: Was ist guter Code für Software-Architekten?
Autoren: Milad Jason Daivandy, Stefan Zörner und Uwe Friedrichsen
Architektur (Teil 1) auf JAXenter
erschienen am 12. September 2016

In dem JAXenter Themen-Schwerpunkt “Schöner Coden” werden die Fragen aufgeworfen: Was ist eigentlich schöner Code? Welche Eigenschaften hat schöner Code aus Sicht eines Software-Architekten? Und umgekehrt: Was macht schlechten Code aus? Hilft ein bestimmtes Tool oder Framework dabei, schöneren Code zu schreiben? Im ersten Teil des Experten-Check beantworten Milad Jason Daivandy, Stefan Zörner und Uwe Friedrichsen diese Fragen und lassen ihre Erfahrungen einfliessen. (…mehr)

„Was macht die Schönheit von gutem Code für Web-Experten aus?“ (Teil 4 der Themenserie)

JAXenter Logo

Teil 4: Was macht die Schönheit von gutem Code für Web-Experten aus?
Autoren: Niko Köbler, Karsten Sitterberg und Oliver Zeigermann
Web (Teil 4) auf JAXenter
erschienen am 19. September 2016

Was ist schöner Code für Web-Experten? Was hilft technisch um schöneren Code zu schreiben? Im vierten Teil des Experten-Check stehen Niko Köbler, Karsten Sitterberg und Oliver Zeigermann Frage und Antwort und erläutern wie wichtig Lesbarkeit und Code-Reviews für sie sind und bei welchen Fehlern sich den Experten im wahrsten Sinne „die Fußnägel hochrollen“. (…mehr)

In der Reihe „Experten-Check: Was ist schöner Code?“ sind die folgenden fünf Artikel auf JAXenter erschienen:

Teil 1: Schöner Code aus Sicht von Software-Architekten (mehr)
Teil 2: Was macht schönen Code für Tester aus? (mehr)
Teil 3: Was ist schöner Code für Mobile und UI-Experten? (mehr)
Teil 4: Was ist schöner Code für Web-Experten? (mehr)
Lesetipps von den JAXenter-Experten: Nach dieser Lektüre schreibst Du schönen Code (mehr)

Artikel im Java Magazin 09/2016: Bring your own Architecture. Softwarearchitektur wird Entwickler-Skill

By | Artikel, Publikationen | No Comments
Bring your own Architecture — Softwarearchitektur wird Entwickler-Skill

Java Magazin 09/2016

Bring your own Architecture — Softwarearchitektur wird Entwickler-Skill
Autor: Stefan Zörner
Artikel im Java Magazin 09/2016, 5 Seiten, Seite 32-36
erschienen am 1. August 2016

Softwarearchitektur beschäftigt sich mit weitreichenden Entscheidungen, die später schwer zurückzunehmen sind. Aktuell liegen hingegen Microservices im Trend, die Applikationen in kleinere Einheiten mit eigenem Entwicklungsteam und individuellem Technologie-Stack aufbrechen. So klein, dass es billiger ist, sie bei Bedarf neu zu bauen. Wenn wir uns falsch entscheiden werfen wir sie einfach weg. Verliert Softwarearchitektur in einem solchen Szenario an Relevanz?

weitere Infos zum Heft

 
follow us on Twitter – @embarced

Artikel im Java Magazin 09/2016: Evolution statt Diktatur. Langlebige Softwarearchitektur und Qualitätsansprüche

By | Artikel, Publikationen | No Comments
Evolution statt Diktatur — Langlebige Softwarearchitektur und Qualitätsansprüche

Java Magazin 09/2016

Evolution statt Diktatur — Langlebige Softwarearchitektur und Qualitätsansprüche
Autor: Stefan Toth
Artikel im Java Magazin 09/2016, 4 Seiten, Seite 38-41
erschienen am 1. August 2016

Wie entstehen gute Software-Systeme? Moderne, State-of-the-Art Lösungen die nicht in 3-5 Jahren einem Ablösungsprojekt zum Opfer fallen. Lösungen die ihre Nutzer begeistern. Antwortmöglichkeit 1: Durch die Arbeit eines einzelnen, genialen Meisters, der alle Einflüsse austariert und einen detaillierten Entwurf der Wahrheit erstellt an den sich alle halten. Antwortmöglichkeit 2: Durch die Nutzung individueller Kompetenzen, um einen lediglich groben Rahmen auszugestalten und kontinuierlich weiterzuentwickeln. Ich bin ein Freund der zweiten Antwort. In diesem Artikel beschreibe ich warum das so ist, wie Freiheit in der Softwareentwicklung weder zu Anarchie noch Chaos führt und wie evolutionäre Architekturen die (Software-)Welt verändern.

weitere Infos zum Heft

 
follow us on Twitter – @embarced

Tests erst in Produktion? Lernen von Microservices

By | Artikel, Publikationen | No Comments
Tests erst in Produktion? – Was wir von Tests bei Microservices lernen können (Artikel auf Informatik Aktuell)

Informatik Aktuell Tests

Tests erst in Produktion? – Was wir von Tests bei Microservices lernen können
Autor: Harm Gnoyke
erschienen am 26. April 2016: online lesen

Microservices sind der meistdiskutierte Architekturstil der letzten Jahre. Für die erhöhte Reaktionsgeschwindigkeit auf Veränderungen zahlen Sie jedoch den Preis einer komplexer zu entwickelnden und zu betreibenden Applikation. Schnell stellt sich die Frage, wie diese Komplexität beim Testen der Anwendung beherrscht wird. Nach ehrlichen Antworten gefragt, räumen viele Projekte ein Defizit bei diesem Thema ein – unabhängig vom gewählten Architekturstil. Wieso werden diese Stimmen rund um Microservices nicht lauter? Was machen die Teams anders, die diese komplexen verteilten Anwendungen entwickeln und betreiben?

zum Artikel

Abheften mit arc42 für Fortgeschrittene. Konzept oder Entscheidung?

By | Artikel, Inhaltliches, Publikationen | No Comments

arc42 ist als Gliederung für Architekturbeschreibungen von Softwaresystemen weit verbreitet, zumindest in D-A-CH. Entsprechend treffe ich häufig auf Projekte, die arc42 benutzen oder beabsichtigen dies zu tun. Im Praxiseinsatz erlebe ich typische Fragestellungen und die immer gleichen Stolperfallen. In diesem Beitrag beschreibe ich kurz, wie ich in Projekten mit einer besonders häufigen Unsicherheit umgehe.

arc42_TOC

8. oder 9. ?

arc42 ist zuallererst eine Strukturierungshilfe. Es weist Inhalten Ihrer Dokumentation einen Ort zu, wo Sie diese „abheften“. Viele Projekte tun sich schwer, bei einem Lösungsansatz zu entscheiden, ob er besser in Abschnitt 8 („Konzepte“) oder 9 („Entwurfsentscheidungen“) passt. Oder in beide? Die Abbildung rechts zeigt die Struktur von arc42 als Inhaltsverzeichnis.

Schnipsel statt Kapitel

Generell rate ich davon ab, arc42 als Dokument (z.B. in Word) auszufüllen. Sie fahren besser damit, Zutaten Ihrer Dokumentation einzeln anzufertigen und sie später zielgruppengerecht in unterschiedlichen Formen zu rekombinieren. Entsprechend spreche ich im Folgenden nicht davon, wo Sie etwas „eintragen“ oder „reinschreiben“ in arc42, sondern wo so eine Zutat oder auch ein Schnipsel (z.B. eine Architekturentscheidung oder ein Konzept) ihren Platz findet.

Für die Einordnung von Entscheidungen, Konzepten sowie für die meiner Meinung nach eng verknüpfte Lösungsstrategie hilft die folgende Tabelle weiter. Ich führe die Inhalte im Folgenden weiter aus.

path-selection-3 document-with-paper-clip-2 american-football-strategy-4
arc42-Abschnitt 9. Entscheidungen 8. Konzepte 4. Lösungsstrategie
Anzahl pro System mehrere, eine pro wichtiger Fragestellung mehrere, eins pro wichtigem Thema eine verdichtete Übersicht, z.B. als Tabelle
Zielsetzung Nachvollziehbarkeit einer Entscheidung breite Kommunikation eines Lösungsansatzes Brückenschlag von Architekturtreibern zu Lösungsansätzen
Leitfrage Warum haben wir uns so entschieden? Wie gehen wir mit dem Thema um? Wie sieht die Lösung grundsätzlich aus?
Typische Form Prosa, stets gleich strukturiert, knapp, häufig mit Kreuztabelle, Prosa, ergänzt mit Abbildungen und (Quelltext-)Beispielen Tabelle (Spalten: Ziel, Ansätze), ggf. ergänzt mit einem Überblicksbild

Entscheidungen

Eoin Woods versteht Softwarearchitektur recht dramatisch als Summe der Entscheidungen, die — wenn falsch getroffen — Ihr Projekt scheitern lassen können. Diese Architekturentscheidungen ändern Sie im weiteren Verlauf nur schwer (oder es wird zumindest teuer); sie wirken breit.

EntscheidungBei Architekturdokumentation geht es vor allem darum solche  Entscheidungen nachvollziehbar festzuhalten. Im Nachhinein ist das schwieriger als beim Entscheiden. Deshalb nutze ich die gleichen Werkzeuge zum Treffen und zum Festhalten der Entscheidung — die Dokumentation fällt dann quasi ab.

Zum Festhalten einer Entscheidung gehören für mich zumindest eine konkrete Fragestellung (z.B. eine Technologie-Auswahl,  Make-Or-Buy …), betrachtete Alternativen und Bewertungskriterien. Kreuztabellen helfen dabei, Argumente verdichtet darzustellen.

Pro Entscheidung fertigen Sie ein einzelnes schlankes Dokument an oder eine einzelne Wiki-Seite oder ein … (das ist jetzt eine Toolfrage). Jede Entscheidung strukturieren Sie dabei gleich. Meine Empfehlung dazu in Kurzform: Fragestellung, Einflussfaktoren, Annahmen, Alternativen, Entscheidung. Am Ende dieses Beitrags finden Sie weiterführende Links dazu, Beispiele inklusive.

Konzepte

Entscheidungen treffen Sie und Ihr Team, um unter gegebenen Rahmenbedingungen Ziele zu
erreichen. Auch Konzepte verfolgen Ziele und sind Teil Ihrer (Architektur-)Lösung. Dieser Umstand macht die Verwirrung aus, wo man was abheftet in arc42.

Konzept
Meine Auslegung: Während Entscheidungen eine Frage beantworten, diskutiert jedes Konzept ein Thema. arc42 schlägt im betreffenden Abschnitt 8 als Unterkapitel viele solcher Themen vor: Persistenz, Sicherheit, … Der zentrale Unterschied aus meiner Sicht: Während es bei den Entscheidungen vor allem um die Nachvollziehbarkeit geht („Warum haben wir uns so entschieden?“), kommunizieren Konzepte vor allem Dinge, die innerhalb Ihres Softwaresystems übergreifend gelöst sind („Wie gehen wir mit einem bestimmten Thema um?“).

Die Zielgruppe eines Konzeptes sind Team-Mitglieder, die das Konzept in ihren Systemteilen anwenden und/oder umsetzen. Entsprechend haben Konzepte idealerweise Tutorial-Charakter und sind mit Beispielen gespickt. Auch für Konzepte schlage ich gern eine an das 4-Quadranten-Modell angelehnte gleichförmige Struktur vor. Sie ist freier als bei Entscheidungen, und gliedert ein Konzept nur grob vier Teile (Warum? Was? Wie? Wohin noch?), nicht feste Kapitel.

Übrigens löst eine Architekturentscheidung gerne das Anfertigen eines Konzeptes aus. In der Entscheidung beschreiben Sie, warum Sie sich für einen Architekturstil oder eine Technologie entschieden haben (Beispiel: Einsatz von Microservices, Verwendung von AngularJS). In Konzepten beschreiben Sie dann Dinge, die übergreifend für alle Services sind, bzw. wie Sie das UI bauen (die Entscheidung für AngularJS lässt einigen Spielraum …)

Die Lösungsstrategie als Klammer

Ein oft vernachlässigtes Kapitel in arc42 ist Abschnitt 4 („Lösungsstrategie“). Ich nutze es gerne um die Brücke zu schlagen zwischen den architekturrelevanten Anforderungen auf der einen Seite (Abschnitte 1-3 in der arc42-Gliederung) und der Lösung auf der anderen.

Lösungsstrategie
Besonders explizit geht dies in einer Tabelle, in der Sie in einer Spalte die Architekturtreiber (z.B. Ihre Qualitätsziele) auflisten, und diesen in der rechten Spalte Lösungsansätze zuordnen. Diese Lösungsansätze können Architekturprinzipien sein, der zugrunde liegende Stil, verwendete Muster, Technologieentscheidungen, Konzepte … In der Tabelle nennen Sie diese nur, und verweisen auf die betreffenden Schnipsel. Die Lösungsstrategie zeigt auf, mit welchen Ansätzen Sie den Qualitätszielen begegnen, und motiviert die Architektur so bereits auf oberster Ebene.

Übrigens …

Das Problem mit dem Einordnen ist besonders gravierend wenn ein Projekt die Architektur nachdokumentiert, Zutaten also nachträglich anfertigt. Bei einem methodischen Vorgehen fallen die Schnipsel auf dem Weg ab und fügen sich nach und nach zu einer Architekturvision und später zu einem konsistenten Lösungsbild.

Zum Abschluss noch die versprochenen Links für Strukturierunsvorschläge, Beispiele inklusive. In meiner Blog-Serie arc42-Starschnitt finden Sie Beiträge zu allen drei genannten Abschnitten:

Die Leseprobe meines Buches zu Architekturdokumentation behandelt Architekturentscheidungen und die Lösungsstrategie ebenfalls, auch mit Beispielen („Kapitel 3: Entscheidungen treffen und festhalten“ als PDF hier herunter zu laden).

Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern oder behindern – Artikel im Business Technology Magazin

By | Artikel, Publikationen | No Comments

 

Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern oder behindern

Business Technology

Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern oder behindern
Autor: Stefan Toth
Artikel im Business Technology Magazin 04/2015 erschienen am 20. November 2015

Online lesen auf JAXenter

Conways Überlegungen werden meist mit der Definition von Schnittstellen und der Systemstruktur in Verbindung gebracht. So versuchen z. B. manche Organisationen, lose Kopplung durch organisatorische Ferne zu fördern. In der momentanen Diskussion zu Systemarchitekturen nimmt Conway, fast fünfzig Jahre nach seiner Feststellung, wieder eine prominente Rolle ein. Wie schaffen es Firmen wie Spotify, Netflix oder Amazon, im Großen sehr effektiv zu arbeiten? Wie können dort hunderte Entwickler an einem Produkt arbeiten, ohne an Dynamik und Reaktionsvermögen einzubüßen? Für schnelle Reaktion auf Marktänderungen werden längst nicht nur Zusammenarbeitsmodelle und Kommunikationsstrategien entwickelt ‑ auch Architekturansätze werden als Teil der Gleichung erkannt. Dieser Artikel zeigt, was agile Softwareentwicklung uns über Teams und Zusammenarbeit lehrt und wie die technische Architektur hier helfen kann.

Online lesen

 
follow us on Twitter – @embarced

Artikel auf JAXenter – Softwarearchitektur in nicht perfekten Umfeldern

By | Artikel, Publikationen | No Comments

 

Softwarearchitektur in nicht perfekten Umfeldern: Agil, Lean oder einfach nur komplex?

JAXenter Logo

Softwarearchitektur in nicht perfekten Umfeldern: Agil, Lean oder einfach nur komplex?
Autor: Stefan Toth
Artikel im Java Magazin 12/2015 erschienen am 04. November 2015

Online lesen auf JAXenter

Viele methodische Entwicklungen der letzten fünfzehn Jahre kann man als Reaktion auf die komplexen Herausforderungen der heutigen Softwareentwicklung verstehen. Agile Vorgehensmodelle versuchen mit Unsicherheit zu leben, Flexibilität im Vorgehen zu ermöglichen und Zusammenarbeit zu stärken. Die richtige Reaktion ist wichtiger als der richtige Plan. Lean stellt das Lernen und stetige Verbesserung in den Vordergrund, versucht Verschwendung zu elimieren und unser Vorgehen auf wichtige Aspekte zu fokussieren. Der Trend geht weit über die Softwareentwicklung hinaus, und selbst wenn Sie den Begriff „Agil“ oder den (abflachenden) Hype darum nicht mögen – es hat sich etwas im Projektalltag verändert und die Disziplin der Softwarearchitektur muss darauf regieren.

Online lesen

 
follow us on Twitter – @embarced

Artikel im Java Magazin 12/2015: Agil, Lean oder einfach nur komplex?

By | Artikel, Publikationen | No Comments

 

Agil, Lean oder einfach nur komplex?

Java Magazin 12/2015

Agil, Lean oder einfach nur komplex?
Autor: Stefan Toth
Artikel im Java Magazin 12/2015, 5 Seiten, ab S. 64
erschienen am 04. November 2015

Online lesen auf JAXenter

Projekte und Produktentwicklungen sind unterschiedlich. Fest steht jedoch: Nirgendwo findet man ein perfektes Umfeld mit ausreichend Geld, Zeit und fähigen Leuten, ohne störende Legacy-Lasten, fehlende Libraries oder böse Überraschungen. Selbst wenn viele dieser Parameter passen, ist Ihr Kunde oder Fachbereich vielleicht wankelmütig oder das Management wechselt während des Vorhabens die eigene Linie (falls es eine gibt). Moderne Softwareentwicklung ist komplex und wenig schablonenhaft. Zeitgemäße Arbeit an der Softwarearchitektur muss deshalb Reaktionsfähigkeit stärken, fokussieren und sich davon verabschieden, dass alles vorab plan- und analysierbar ist.

Agile Vorgehensmodelle versuchen mit Unsicherheit zu leben, Flexibilität im Vorgehen zu ermöglichen und Zusammenarbeit zu stärken. Die richtige Reaktion ist wichtiger als der richtige Plan. Lean stellt das Lernen und die stetige Verbesserung in den Vordergrund, versucht Verschwendung zu eliminieren und unser Vorgehen auf wichtige Aspekte zu fokussieren. Der Trend geht weit über die Softwarearchitektur hinaus, und selbst wenn Sie den Begriff „Agil“ oder den (abflachenden) Hype darum nicht mögen – es hat sich etwas im Projektalltag verändert und die Disziplin der Softwarearchitektur muss darauf reagieren…

weitere Infos zum Heft

 
follow us on Twitter – @embarced

Single Page-Anwendungen – Vorteile von Web und Desktop kombiniert

By | Artikel, Inhaltliches | No Comments

Desktop-Anwendungen und klassische Web-Anwendungen haben – jede für sich – große Vorteile. Eine Desktop-Anwendung ist in ihrem Bedienkomfort und auch in ihrer Reaktionsgeschwindigkeit typischerweise der klassischen Web-Anwendung überlegen. Diese muss nämlich für jede Interaktion mit dem Benutzer eine komplett neue Seite auf dem Server rendern und diese wieder zum Browser übertragen. Das ist auch bei modernster Technik zu langsam, um mit einer Desktop-Anwendung zu konkurrieren. Dazu schließt sich ein Offline-Betrieb einer solchen Web-Anwendung schon von selbst aus: ohne Verbindung zum Server kann man auch nichts darstellen. Auf der anderen Seite läuft eine Web-Anwendung auf jeder Plattform, die einen Internet-Browser hat und muss nicht installiert oder aktualisiert werden. Wenn man sich etwas Mühe mit Responsive Layout gibt, funktioniert eine solche Anwendung sogar auf einem mobilen Gerät.

Die klassische Web-Anwendung

Gucken wir uns dazu die folgende Darstellung einer klassischen Web-Anwendung an. Der Anwendungszustand, die Geschäftslogik und der UI-Teil, der die Anwendung in HTML transformiert, ist auf dem Server. Der Browser macht lediglich Anfragen über HTTP und bekommt HTML-Seiten geliefert, die er nur noch darstellen muss. Jede Interaktion erfordert also einen Request zum Server, gefolgt von der Response mit der neuen Darstellung:

Classic Web Application

Klassische Web-Anwendung, Lila: Browser, Blau: Server

Grenzen der klassischen Web-Anwendung

Dieser Ansatz ist erfreulich einfach, kommt aber immer mehr an seine Grenzen, je interaktiver die Anwendung wird. Stellen Sie sich z.B. eine Tabelle vor, bei der sich die Breite jeder einzelnen Spalte durch Ziehen mit der Maus ändert. Oder einen interaktiven Editor für Text, wie diesen. Wenn wir das Modell beibehalten wollten, müssten wir bei jeder Interaktion einen Request/Response-Roundtrip durchführen. Das ist zum Einen technisch ohne den Einsatz von JavaScript-Logik im Browser nicht möglich, zum Anderen hätten wir dann eine große Anzahl von Anfragen (jeder Click und jeder Tastendruck im Extremfall). Eine derartige Anwendung wäre zwar technisch denkbar, würde aber nicht zu einer guten Benutzer-Erfahrung führen. Die Anwendung wäre langsam, würde flackern und wäre generell von der Latenz von Server und Netz abhängig.

Gängige Muster nutzen für derartige Anwendungen daher eher punktuelle JavaScript-Logik, z.B. in Form eines jQuery-Plugins für einen Text-Editor oder eine Tabelle. Dies erfordert allerdings das Halten von Zustand im Browser zusätzlich zu dem Zustand auf dem Server. Soll der Zustand des Browsers über eine Request/Response-Grenze hinweg gehalten werden, so muss dieser als Teil des Requests zum Server übertragen und als Teil des Response zurück übertragen werden. Für einen Text-Editor würde das z.B. auch die Cursor-Position, die Scroll-Position und alle aktuell gewählten Format-Optionen beinhalten. Dies stößt oft an die Grenzen der Plugins und würde auch keinen Best-Practice darstellen. Stattdessen wird für die Lebensdauer einer solchen Komponente häufig auf komplette Server-Roundtrips verzichtet und man hat eher eine Ansammlung von kleinen Browser-Anwendungen innerhalb der klassischen Web-Anwendung. Eine solche Architektur ist möglich, ist aus unser Erfahrung aber ein Grund für den schlechten Ruf von Web-Anwendungen. Die temporäre Verteilung des Zustands auf Browser und Server, die unklare Trennung der Verantwortlichkeiten, die Mischung von Darstellung des HTMLs auf Browser und Server machen eine solche Anwendung häufig aufwändig in der Entwicklung und Wartung.

Single-Page Applications als Lösung

Der Kern des Problems liegt dabei darin, dass Benutzer-Interaktion, Zustand und Programmlogik nicht oder nur zeitweilig nahe beieinander liegen. Der Zustand ist zudem verteilt über Server und Browser, teilweise redundant und zeitweise sogar inkonsistent. Architektonisch ist es reizvoll, dies zu vereinheitlichen und alles nah bei einander zu haben. Da die Benutzer-Interaktion per Definition im Browser liegt, gibt es Ansätze auch Zustand und zumindest den UI-Teil der Programmlogik ebenfalls in den Browser zu verschieben. Das Versprechen ist dabei auch, die Vorteile der Welten Desktop und klassischer Web-Anwendung kombinieren zu können. Den Bedienkomfort, die Reaktionsgeschwindigkeit und die Offline-Fähigkeit der Desktop-Anwendung mit der Verfügbarkeit und der einfachen Installation einer Web-Anwendung? Das geht in der Tat. Und es gibt sogar einen Namen dafür: eine Single-Page Application oder kurz SPA:

SPA Web Client

Single-Page Application, Lila: Browser, Blau: Server

Die Idee dabei ist, die Anwendungs- und UI-Logik näher an den Anwender, also in den Browser, zu bringen und hier auch die komplette Darstellung zu implementieren. Dabei wandert auch der Zustand der Anwendung vom Server komplett in den Browser und damit wäre der Zustand immer synchron, da es schlicht keinen Server-seitigen Zustand mehr gibt. Der Server liefert am Anfang nur eine einzige Webseite aus, die allen Code enthält. Danach dient der Server nur noch dazu, die SPA mit Daten zu versorgen oder Daten zum Speichern entgegenzunehmen. Auf diese Weise kann eine SPA tatsächlich mit einer Desktop-Anwendung konkurrieren. Selbst ein Offline-Betrieb wäre möglich, hierzu müsste zumindest ein Teil der Geschäftslogik im Browser vorhanden sein. Für den Fall einer ungenügenden Internet-Versorgung könnte das nützlich sein, z.B. während Reisen mit der Bahn oder im Flugzeug. Beispiele solcher Anwendungen sind Google Docs und Spreadsheets, Word Online oder auch Facebook.

Herausforderungen bei Single-Page Applications

Es ergeben sich allerdings für SPAs eine Reihe von Herausforderungen. Selten haben Unternehmen ein großes Know-How in der Anwendungsentwicklung mit JavaScript. Entwickler beherrschen vielleicht Java oder C# und stehen JavaScript und seiner Kultur skeptisch gegenüber. In den Grafiken oben stellen wir zudem die Beziehung der Anwendungsschichten zu Anforderungen im Bereich Stabilität und Langlebigkeit dar. Je weiter wir uns in der Pyramide nach unten bewegen, desto höher die Anforderung. In unseren Blog-Posts JavaScript im Großprojekt – TypeScript und andere Typensysteme beschäftigen wir uns mit den Mängeln von JavaScript im Unternehmenskontext und was man dagegen tun kann. Hier empfehlen wir auch für Enterprise-Projekte auf TypeScript zu setzen. In verschiedenen Projekten haben wir direkt miterlebt, wie schnell die Sprache TypeScript unter Java- und C#-Entwicklern zur Gewohnheit wird.

Die Auswahl eines passenden JavaScript Web-Frameworks ist leider auch keine einfache Aufgabe, da der Bereich unübersichtlich und in ständiger Bewegung ist. Unsere Erfahrungen dazu haben wir in den Blogposts über JavaScript-Web-Frameworks und UI-Architektur festgehalten.

Blogserie auf JAXenter: „LiesMich.jar – Bewusster Umgang mit 3rd Party Libraries“

By | Artikel, Publikationen | No Comments
„LiesMich.jar – Bewusster Umgang mit 3rd Party Libraries“ (Blogserie auf JAXenter)

JAXenter Logo

LiesMich.jar – Bewusster Umgang mit 3rd Party Libraries
Blogserie von Harm Gnoyke
Teil 1
Teil 2
erschienen am 22./29. September 2015

Eine 3rd Party Library ist in Java schnell und unkompliziert eingebunden. Entwickler freuen sich über die gesparte Zeit und die geschenkte Funktionalität. Auch der Projektleiter ist froh, kann er nun den Entwickler wieder an richtigen Features arbeiten lassen. Doch heißt „geschenkt“ auch wirklich kostenlos? Natürlich ist die Antwort darauf „Nein“, denn ein Projektteam sollte Folgekosten und Risiken bei solch einer Entscheidung immer berücksichtigen. (mehr …)

zu Teil 1 zu Teil 2