Sebastian Springer auf der IPC 2014

JavaScript-Architekturen mit Köpfchen [IPC 2014]
Kommentare

JavaScript kann jeder, oder? Tja, hm – nicht wirklich! Wenn es darum geht, ernsthafte Anwendungen jenseits der 1 Millionen Lines-of-Code-Grenze zu bauen, reicht es nicht mehr, mit seinem JS-(Halb)Wissen bedenkenlos loszuskripten. Spätestens wenn es um Budgets in Millionenhöhe geht, sind Überlegungen zu nachhaltigen Architektur-Prinzipien einer Webanwendung dringend anzustellen, soll einem die App in 2,3 Jahren nicht um die Ohren fliegen. Welche grundlegenden Weichstellungen man für eine JS-Architektur vornehmen sollte, verriet uns Sebastian Springer (Mayflower) auf der IPC 2014.

Wozu Architektur?

Damit der Code einer JS-Webanwendung nicht aussieht wie ein Haufen Spagetti, lohnt es sich, sich zu Beginn die Ziele vor Augen zu halten, die man mit einer sauberen Architektur erreichen will. Sebastian Springer definiert diese schlüssig:

  • Wartbarkeit
  • Erweiterbarkeit
  • Testbarkeit
  • Modularisierung in unabhängige Komponenten
  • Ermöglichung der parallelen Arbeit im Team

Als nächsten Schritt sollte man sich klar machen, welche Art von Webanwendung man entwickelt. Während bei Multi-Page-Installationen JavaScript nicht mehr als eine Unterstützung darstellen sollte, wird bei Single-Page-Anwendungen  typischerweise die gesamte Businesslogik in JavaScript abgebildet. Um solche Single-Page-Projekte geht es im Folgenden; Beispiele solcher Projekte sind etwa Facebook, twitter, cloud9 …

Zentral ist bei solchen Single-Page-Projekten die saubere Trennung zwischen Client und Server. Client Source Code wird statisch vom Server ausgeliefert. Nutzdaten werden per AJAX(-artigen) Request im JSON-Format nachgeladen. So wird auch die Teamaufteilung in Frontend- und Backend-Entwickler möglich.

Wichtig dann die Separierung der Sprachen: Pro Datei nur eine Sprache. HTML wird für die Seitenstrukturierung verwendet, CSS für das Layout, JavaScript für die Logik.

Bitte vermeidet unbedingt Inline-Scripting.

Schöne modulare Welt

Das nächste Thema Modularisierung steht und fällt mit der vorsichtigen Verwendung des Global Scope in JavaScript. Globale Variablen führen nämlich schnell zu Namenskonflikten im Namensraum, verhindern die Wiederverwendbarkeit von Komponenten und erschweren eine modulare Erweiterung.

Zurückgreifen sollte man nur auf Konstanten als globale Werte, auf Funktionsparameter und Dependency Injection, das z.B. von Frameworks wie Angular.js bereit gestellt wird.

Vom Grundprinzip her sollte man die Anwendung von einem Applikationskern aus konzipieren, der die Infrastruktur und Integrationsplattform für weitere Module bietet. Sehr oft wird dieser Kern von einem Framework geliefert werden. Um diesen Kern herum gruppieren sich dann die Module, die idealerweise je ein isoliertes Feature implementieren.

Welches Architekturpattern?

Etwas theoretischen Überbau liefern Architekturpattern: MVC, MVP, MVVM.

Sebastian Springer zeigt unterschiedliche Architekturpattern

Wem die Unterschiede hier zu akademisch sind, dem empfiehlt Springer das Google-Pattern  MVW: „Model View Whatever works for you“. Geboren wurde MVW aus der Erfahrung heraus, dass es hauptsächlich auf die Separation von Datenhaltung und Anzeigelogik ankommt (Model / View) und man schnell in fruchtlosen Diskussionen versinkt, ob nun ein Controller oder Presenter oder gar ein ViewModel nötig ist.

Frameworks

Zwei klare Aussagen von Sebastan Springer zum Thema Frameworks:

  • Es gibt nicht das perfekte Framework!
  • Ohne Framework geht es nicht!

Wer bei der letzten Aussage nun entrüstet aufschreit, darf sich wieder setzen, wenn wir dazusagen, dass damit auch kleine, intuitiv geschriebene Frameworks gemeint sind. Es geht einfach darum, dass häufig auftretende Problemstellungen zentral gelöst werden und Strukturierungselemente zur Verfügung gestellt werden – das macht praktisch jeder automatisch und ist in groß angelegten Projekten unvermeidbar. Wer auf etablierte Frameworks setzt, wird zudem die Erfahrung machen, dass diese bei später auftretenden Problemen oft schon die passende Lösung parat haben.

Denn es ist in unserem Metier sehr wahrscheinlich, dass Eure Probleme nicht SO speziell sind, dass sie nicht schon ein anderer einmal gehabt und gelöst hätte.

Zum Schluss deklinierte Springer auch einige Beispiele für etablierte Frameworks durch: Backbone.js, Ember.js, Angular.js – und Module Loader wie Require.js und common.js modules. An dieser Stelle sind allerdings weiterführende Quellen heranzuziehen – beispielsweise die Sessions des Framework Days auf der IPC. Die Ergebnisse der dortigen Diskussionen haben wir hier übrigens für Euch zusammengefasst: Frameworks oder nicht – das ist hier die Frage.

JavaScript mit Köpfchen

JavaScript muss nicht in kopflosem Spaghetti-Code enden. Mit Sebastian Springers Richtschnur liegt man hier auf Kurs – und das ist schon einmal Gold bzw. viel bahres Geld bei Business-kritischen Anwendungen wert!

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -