Einfache JavaScript-Architekturen für Ihr Projekt

Wo ist meine Architektur? Welche Architektur?

22. August 2013Patrick Dahms

In der Entwicklung von aktuellen und modernen Weboberflächen führt kein Weg an JavaScript vorbei – soviel steht fest. Die Frage ist, wie geht man im Projekt beziehungsweise im Team damit um? Auch wenn JavaScript von vielen Entwicklern nicht als solche angesehen wird, ist und bleibt sie eine Programmiersprache und sollte auch dementsprechend behandelt werden. Beispielsweise werden im Back-End die verschiedensten n-Tier-Architekturen hoch professionell entwickelt, jedoch werden in der Clientside-Entwicklung Richtlinien oder Best Practices einfach ignoriert oder vergessen – Stichwort: DRY, Codestyle, Tests oder eben eine Architektur.

Bevor wir uns Gedanken über eine Architektur machen, benötigen wir erst mal ein Grundverständnis darüber, was eine schlechte Architektur ist und woran wir diese erkennen können. Eine mangelhafte oder fehlende JavaScript-Architektur kann an den folgenden Punkten erkannt werden:

Inline JavaScript

Inline JavaScript ist ein sehr häufig auftretendes Problem. Dabei werden JavaScript-Fragmente direkt inline im HTML-Code hinterlegt. Zum Beispiel kleinere Code-Snippets oder das direkte Binding von Event-Listenern:

<script>

function showTooltip(text) {

// do magic

}

</script>

<input type=”text” onfocus=”showTooltip(‘Pflichtfeld!’);”/>

Die Gründe für inline JavaScript liegen eigentlich auf der Hand. Wie in dem Beispiel ist direkt beim Eingabefeld sichtbar, welches JavaScript für den Tooltip verantwortlich ist. Dadurch wird doch die Wart- und Lesbarkeit erhöht – wo ist das Problem? Das stimmt natürlich, aber nur, wenn folgendes nicht eintritt oder im Projekt keine Rolle spielt:

  • Änderbarkeit der Funktions-Signatur (neue Parameter)
  • Neue Event-Listener sollen hinzugefügt werden
  • Doppelter Code. Ein Script liegt schwer sichtbar in einer Schleife und wird so, je nach Anzahl an Elementen, dupliziert
  • Caching. Das Script kann nicht vom Browser gecached werden

Globale Variablen und Functions

In dem Tooltip-Beispiel vom oben gibt es noch ein weiteres Problem. Alle Funktionen und Variablen, die auf diese Art angelegt werden, liegen im globalen Scope. Das bedeutet, wir können von jedem Punkt aus, in einem beliebigen Skript-Fragment, diese Funktionen aufrufen oder Variablen verändern. Skripte können dadurch unter Umständen falsch ablaufen. Beispiel: zwei Funktionen greifen auf die gleiche globale Variable zu (Zählervariable, wie index oder i). Zusätzlich können an anderer Stelle im HTML-Code die Funktionen ungewollt mit einem anderen Verhalten überschrieben werden, ohne eine entsprechende Fehlermeldung. JavaScript ist eben sehr dynamisch.

Hohe Anzahl an JavaScript-Dateien

Viele JavaScript-Dateien (externe und interne) sind prinzipiell nicht schlecht. Damit wird zum Beispiel das Problem von ungenutztem Code zur Laufzeit umgangen. Wieso seitenspezifischen Code ausliefern, wenn der Benutzer gar nicht auf dieser Seite ist? Hinzu kommen oftmals die vielen (jQuery) Plugins mit ihren einzelnen Dateien. In der Entwicklung ist die Aufteilung von Funktionalitäten in verschiedene Dateien gut, jedoch für das Produktivsystem nachteilig. Jede zusätzliche JavaScript-Datei wird per Request einzeln vom Server angefordert. Das kann an der Performance der Webseite ziehen (Page-Load-Time).

Keine Separierung oder Kapselung von logischen Einheiten

Jede neue Funktionalität wird einfach am Ende der Haupt-JavaScript-Datei angehängt. Dadurch entsteht sehr schnell ein Durcheinander von Funktionalitäten – Initialisierungen, Listener-Bindings oder Plugin-Aufrufe. Die JavaScript-Datei wird dadurch sehr schwer les- und wartbar, vor allem, wenn sie viele 1000 Zeilen lang ist.

Keine Testabdeckung

Je mehr Logik in den Client verschoben wird, desto größer ist die Gefahr, bei Änderungen etwas anderes ungewollt zu verändern oder kaputt zu machen. Eine Testabdeckung im Back-End steht außer Frage, warum also nicht auch für den eigenen JavaScript-Code? JavaScript ist oftmals schwer testbar, gerade wenn es viele AJAX-Aufrufe gegen das Back-End gibt. Mit einer richtigen Strukturierung, ist aber auch das möglich.

Das waren nur einige Punkte, wie eine schlechte Architektur erkannt werden kann. Es gibt mit Sicherheit noch viele weitere Indikatoren. Jedes Projekt sollte darüber hinaus auch individuell betrachtet werden. Sie können sich aber auch einfach mal die folgenden Fragen stellen:

  • Verstehe ich, was meine Skripte wann und wo machen?
  • Kenne ich meine Abhängigkeiten zu allen externen Bibliotheken und/oder Plugins?
  • Kann ich Änderungen an bestehenden Skripten vornehmen, ohne Angst haben zu müssen irgendwo etwas kaputt zu machen?

Da ein JavaScript MVC-Framework, wie angular, backbone oder ember für die meisten Projekte aus unterschiedlichen Gründen schwer einsetzbar ist, müssen Alternativen geschaffen werden. In meinem nächsten Beitrag zeige ich, wie mit verschiedenen Minimal-Architekturen einige der oben genannten Probleme gelöst werden können.

Haben Sie Fragen zu diesem Beitrag? Ich freue mich auf Ihre Kommentare.

Patrick Dahms Patrick Dahms ist Softwareentwickler am adesso-Standort Berlin mit Fokus auf Java, HTML5 und JavaScript.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentare

Karl 14. Dezember 2014

für mich wird Javascript nie eine Programmiersprache sein 😉

Kommentar hinzufügen:

Ihr Kommentar: