Wenn Code schlecht wird, Teil 3 – JavaScript haltbar machen

Kein Beitragsbild

Chris Heilmann (Übersetzung Manuela Müller)

Wie Sie vermeiden, dass andere Entwickler oder so genannte Maintainer sich später über Ihren Code ärgern, ist Thema dieser Artikelserie – in Teil 3 geht es um JavaScript.

JavaScript ist die am häufigsten eingesetzte und womöglich auch wirkungsvollste Programmiersprache, die zur Zeit verfügbar ist. Dass sie so beliebt ist, liegt vor allem an diesen Vorzügen:

  • JavaScript ist einfach zu erlernen.
  • Der Code muss nicht kompiliert werden – es ist kein Server nötig.
  • Die Sprache ist allgegenwärtig.

Es gibt keinen sinnvollen Grund, JavaScript für bestimmte, mit ihm hervorragend zu lösende Aufgaben nicht einzusetzen. Auch deshalb, weil die zunehmende Verbreitung von JavaScript Object Notation, kurz JSON – inzwischen der Quasi-Standard für Datentransfer, und zahlreiche JavaScript-Bibliotheken browserübergreifendes Programmieren und die Manipulation verschachtelter Dokumente via JavaScript DOM (Document Object Model) sehr vereinfacht haben.

Und genau hier wird’s problematisch: Da JavaScript so einfach zu erlernen und anzuwenden ist (Bibliotheken verführen bestimmte Leute zur Annahme, dass es nur dieser einen Bibliothek bedarf) halten sich manche viel zu früh in ihrer Karriere für kompetente JavaScript-Entwickler. Ich führe derzeit Vorstellungsgespräche mit möglichen Kandidaten für eine Position als Front-End-Entwickler und bin sehr erstaunt darüber, wie viele Leute, die lediglich jQuery kennen, sich um diese Stelle bewerben. Das Anwenden einer bestimmten Technik macht noch nicht zum Experten. Wenn man nicht einmal weiß, wie und warum etwas funktioniert, dann ist man nicht in der Lage ein Produkt zu pflegen. Wenn Sie irgend etwas einsetzen, sollten Sie dafür sorgen, dass es funktioniert und dass Sie wissen, wie Sie das Problem beheben können, wenn es nicht mehr funktioniert.

Bei den folgenden Punkten sollten bei Ihnen bereits beim Entwickeln von JavaScript die Alarmglocken schrillen:

  1. Schreiben von “aufdringlichem” JavaScript
  2. Wenn Sie sich darauf verlassen, dass die Daten im richtigen Format vorliegen.
  3. Anwenden ohne zu testen
  4. Mangelnde Planung für den Problemfall
  5. Fehlende Konfigurierbarkeit der Scripte
  6. Unzureichendes Testen und Validieren Ihres JavaScripts

1. Aufdringliches JavaScript

Ich habe es im ersten Teil dieser Artikelserie schon einmal gesagt: Wenn Sie HTML schreiben, das nur Sinn ergibt, wenn JavaScript verfügbar ist, schaffen Sie sich Ihre Probleme selbst. Ein Schnittstellenelement, das nichts tut, wenn ich es aktiviere, ist ein gebrochenes Versprechen des Anbieters an den Anwender. Damit verlieren die Anwender folglich das Vertrauen in Ihre Schnittstelle. Aus diesem Grund predige ich seit Jahren, unaufdringliches JavaScript zu entwickeln; in letzter Zeit erhalte ich dafür Unterstützung. Der Trick besteht darin, vor dem Einsatz einer bestimmten Technik oder einer Funktion zu testen, ob diese Funktion auch ausgeführt werden. Das ist genauso einfach und selbstverständlich wie das Prüfen der Tiefe eines unbekannten Gewässers, bevor Sie kopfüber hinein springen
“Müllen” Sie Ihre Dokumente daher nicht mit javascript://-Links zu, entfernen Sie solche onclick=""-Handler und schaffen Sie Dinge, die im üblichen funktionieren sollten, wenn JavaScript mit JavaScript gebraucht wird. Das ist keine Zauberei und der Aufwand lohnt sich in hohem Maße.

2. Sich darauf verlassen, dass die Daten im richtigen Format vorliegen

Daten sind niemals sauber, vor allem dann nicht, wenn Sie vom Endanwender kommen. Wenn Sie Code schreiben wollen, der funktioniert, sollten Sie gewährleisten, dass die eingegebenen Daten getestet werden, bevor Sie diese weiter verarbeiten. JavaScript bietet jede Menge Funktionen, mit denen Sie testen können, ob ein bestimmter Parameter ein String, ein Bereich (Array), eine Zahl, ein Objekt – oder was auch immer Sie benötigen – ist. Indem Sie reguläre Ausdrücke verwenden oder Typen vorgeben, können Sie sicher stellen, dass in Ihre Schnittstelle nur solche Daten eingegeben werden, die Ihr Code auch verarbeiten kann und daher nicht ins “Stottern” gerät. Hören Sie bitte auf, unzuverlässigen Code wie den folgenden zu schreiben:

Kennst du unser E-Book-Bundle? Spare jetzt 6,99 €!

E-Book Bundle von Andreas Hecht
function loopOver(x){
  for(var i=0,j=x.length;i<j;i++){
      doStuffWith(x[i]);
  }
}

Der obige Code geht davon aus, dass “x” ein Array ist, aber Sie können das nicht wissen. Daher sollten Sie es lieber prüfen:

function loopOver(x){
  if(typeof x === 'object' && x.length !== 'undefined'){
    for(var i=0,j=x.length;i<j;i++){
        doStuffWith(x[i]);
    }
  }
}

Validierung ist eine sehr wichtige Voraussetzung für sauberen Code. Ein JavaScript, das Daten in ein Dokument einfügt, ohne diese vorher zu bereinigen, kann das Script nicht nur funktionsuntüchtig machen – es stellt außerdem ein Sicherheitsrisiko dar.

3. Anwenden ohne zu testen

JavaScript in Browsern ist unzuverlässig. Jegliches andere Script auf der Seite kann die Funktionstüchtigkeit Ihres Scripts erheblich beeinträchtigen. Außerdem können Websites, die in anderen geöffneten Tabs oder Fenstern laufen, die Leistung des Browsers beeinträchtigen. Um wirklich zu wissen, wie Ihr Script sich verhält, ist es nicht genug, es lokal zu testen und es ein paar Mal laufen zu lassen. Es ist erforderlich, dass Sie Ihr Script in einer realen Umgebung zusammen mit allen möglichen anderen Scripten, mit denen es unter normalen Umständen harmonieren müsste, zu testen. Eine bedeutende Fehlerursache sind langsame Internetverbindungen. Testen Sie deshalb Ihre Scripts mit einer langsamen Verbindung oder simulieren Sie eine langsame Verbindung mit einem Proxy-Server – zum Beispiel mit Sloppy, bevor Sie Ihren Code zum Einsatz freigeben.

Ein anderer Fall von “Anwenden ohne zu Testen”, der Ihren Code schlecht werden lässt, besteht darin, tief verschachtelte Objekte oder DOM-Selektoren zu verwenden.

for(var i=0,j=data.results.houses.levels.flats.length;i<j;i++{
  // ...
}
$('#main #message li a span').hide();

Sie gehen “wiederum” davon aus, dass data.results.houses.levels.flats existiert, obwohl Sie sich nicht darauf verlassen können. Sie müssen bis zur untersten Ebene des Pfads prüfen, ob die angegebene Eigenschaft tatsächlich vorhanden beziehungsweise korrekt ist, bevor Sie den Loop einsetzen können. Ist die Eigenschaft nicht vorhanden – etwa dann, wenn das HTML-Template geändert wurde, wird Ihr Script nicht mehr funktionieren. Sofern Sie mit jQuery arbeiten wird Ihr Script still und leise fehlschlagen, was das Debuggen zu einem frustrierenden Erlebnis machen kann.

4. Mangelnde Planung für den Problemfall

Wenn Sie eine bestimmte Funktion anwenden, sollten Sie auch Maßnahmen für den Problemfall oder das Nicht-Funktionieren einplanen. Auf diese Weise können Sie Fehler registrieren oder dem Anwender zumindest sagen, dass etwas schief gelaufen ist, wenn etwas schief läuft. Und es geht immer etwas schief: Ajax-Anfragen ohne Timeout-Meldung oder Fehlermeldungen führen dazu, dass die Anwenderschnittstelle nicht regiet, so dass die Anwender versuchen, das Dokument neu zu laden.

Click-Händler, die nicht auf eine Seite zum erneuten Laden zurückfallen, die eben genau das tun – nämlich neu laden – werden zu nervigen Buttons führen, die Anwender wieder und wieder anklicken, ohne eine entsprechende Rückmeldung zu erhalten.

Die Lösung ist recht einfach. Bauen Sie Möglichkeiten fürs Fehlermanagement in Ihren Code ein (selbst wenn Sie diese Code-Teile nur als Platzhalter oder Marker einfügen). Damit sorgen Sie dafür, dass Ihr Code stets erweiterbar ist. Planen Sie nicht für Fehlleistungen und es treten Fehler auf, werden Maintainer Ihren Code ersetzen, anstatt zu versuchen, das Problem zu beheben.

5. Fehlende Konfigurierbarkeit Ihres Scripts

Die Beziehung zwischen HTML und JavaScript ist heute sehr groß. Bibliotheken wie jQuery empfehlen dies als einen schnellen Weg, tolle Websites zu bauen und die Ergebnisse bestätigen das ja auch. Indem wir also HTML und JavaScript miteinander koppeln, machen wir es den späteren Maintainern unseres Codes aber auch sehr einfach, das betreffende Script zu ändern oder zu ruinieren, falls sich die Hierarchie der HTML-Struktur ändert, werden lange Selektoren, nicht mehr funktionieren. Um es den Maintainern möglichst einfach zu machen, ist es daher wichtig, alle Selektoren am Anfang des Skripts zu notieren und die Ergebnisse im Cache zu speichern. Damit machen Sie es Maintainern einfacher, die Selektoren zu ändern, wenn das erforderlich ist.

Das gilt übrigens generell – wenn Sie es anderen Personen erleichtern möchten, Ihren Code zu pflegen, sollten Sie alles, was sich mit großer Wahrscheinlichkeit ändern könnte (etwa IDs, Klassen, DOM-Pfade, Strings und Parameter) in ein Konfigurationsobjekt einfügen. Ich habe darüber schon mehrfach geschrieben (Link) und dies ist nach wie vor die wirkungsvollste Methode, um Ihren Code vor späteren fehlerhaften Eingriffen durch Maintainer zu schützen.

6. Unzureichendes Testen und Validieren Ihres JavaScripts

Last but not least it is important to write clean JavaScript code that validates and works even when it gets converted by a script to improve web site performance. A lot of servers do get set up to minify or pack JavaScript these days and your scripts should not break when that gets done to them. The main trick here is to use curly braces and not rely on semicolon injection by the browser. The easiest way to see if your JavaScript is ready to go out is to run it through JSLint. JSLint is also available as an add-on for many editors out there so validating your script becomes part of saving it.

Zu guter Letzt kommt es darauf an, JavaScript-Code zu schreiben, der selbst dann valide ist, wenn der Code von einem anderen Script konvertiert wird, um die Leistung der Website zu verbessern. Eine Reihe von Servern sind so konfiguriert, dass sie JavaScript reduzieren oder packen. Achten Sie also darauf, dass Ihr Script durch solch ein Verfahren nicht beschädigt wird. Der Haupttrick besteht darin, geschweifte Klammern zu verwenden und sich nicht darauf zu verlassen, dass der Browser an der richtigen Stelle Semikolons einfügt. Lassen Sie Ihr JavaScript durch JSLint – so können Sie am einfachsten prüfen, ob es reif für die Veröffentlichung ist. JSLint ist für viele Editoren als Add-On  verfügbar – das Validieren Ihres Scripts sollte also zum integralen Bestandteil des Speicherns werden.

Wenn Sie vermeiden möchten, dass Ihr JavaScript-Code schlecht wird, ist es grundsätzlich immer gut, das fertige Script noch einmal auf Herz und Nieren zu prüfen, wenn Sie selbst mit dem Script fertig und zufrieden sind. Vor zwei Jahren habe ich eine Handlungsanleitung mit 5 Aktionen erstellt, denen Sie Ihr Skript unbedingt unterziehen sollten, bevor Sie es an andere Entwickler weitergeben. Daran hat sich bis heute nichts geändert und die Liste hat nach wie vor ihre Gültigkeit.

Fazit

Eine Reihe von Gründen, warum Code mit der Zeit wertlos wird, sind vor allem administrative Gründe. Sie können allerdings eine ganze Menge tun, um Ihren Code gut pflegbar zu halten, indem Sie den Aspekt der Wartung bei der Entwicklung immer mit berücksichtigen. Außerdem sollten Sie quasi eine Art “Verfolgungswahn” in Bezug auf änderungsanfällige Elemente, die essentiell für die Funktionsfähigkeit Ihres Codes sind, an den Tag legen. So können Sie am besten verhindern, dass Sie relativ bald von unliebsamen Mutationen Ihres Codes überrascht werden.

Die Quintessenz des Ganzen ist, dass Sie Ihren Code sehr sorgfältig planen und eine wohldurchdachte Architektur entwerfen sollten, anstatt das Script einfach herunter zu schreiben und sich damit zufrieden zu geben, dass es in Ihrer Umgebung läuft. Dies ist eines der Hauptunterscheidungsmerkmale zwischen einem Hobbyprogrammierer und einem professionellen Webentwickler.