Seite 4: Dokumentation, Debugging, Performance & Deployment

Inhaltsverzeichnis

Dokumentation, Debugging, Syntax-Check & Profiling

Für das Kommentieren von Funktionen (und jeder anderen Stelle in JavaScript) sollte die mittlerweile übliche ScriptDoc-Syntax verwendet werden:

/**
 * Ich bin ein Kommentar zur Funktion "Test"
 * @param {String} name
 */
function test(name) {
    
}

Das ist ein Funktionskommentar, der zeigt, dass sich ein Parameter name an die Funktion test übergeben lässt. Nützlich ist auch, dass Aptana diese Kommentare auslesen und bei der Code-Completion während des Schreibens direkt anzeigt.

Mit einem Werkzeug wie dem jsdoc-toolkit können die Kommentare weiterhin in HTML- oder XML-Dateien gesammelt werden und bilden somit eine gute Ausgangsbasis für die weitere Dokumentation.

JavaScript läuft ausschließlich im Browser, daher liegt es nahe, Webapplikationen direkt im Browser zu debuggen. Eine nützliche Bibliothek ist log4javascript.js, das auf dem Werkzeug log4j basiert. Es gibt die Log-Messages entweder in den Entwicklungstools aktueller Browser oder in einem eigenen Pop-up aus – das funktioniert dann selbst in antiken Browsern wie dem IE5. Dabei bietet log4javascript mehrere Loglevel, die auch optisch unterschiedlich dargestellt sind. Weiterhin können die Meldungen auch an den Server zurückgegeben und dort zum Beispiel in ein Logfile geschrieben werden.

In allen bisher gezeigten Listings wurden bereits log4javascript-Aufrufe gesetzt – es genügt eine Zeile wie log.debug(Fehlermeldung) im Code. Für die Entwicklung ist das hilfreich, aber auf einem Live-System möchte man derartige Meldungen nicht sehen. Normalerweise müsste man also händisch oder per Skript alle log-Aufrufe aus dem Quelltext entfernen. log4javascript bringt zu diesem Zweck eine nur etwa 5 KByte kleine "Stub"-Bibliothek mit, die in die Live-Umgebung anstelle des regulären log4javascript.js eingebunden werden sollte. So können alle Aufrufe im Code bleiben, erzeugen aber keine Ausgabe mehr.

Breakpoints (inklusive Bedingungen) lassen sich übrigens auch direkt in Firebug setzen, man ist also nicht auf Eclipse angewiesen. Der Vorteil ist, dass parallel auch alle weiteren Firebug-Tools zur Verfügung stehen und man die Anwendung über JavaScript hinaus debuggen kann.

Um den geschriebenen JavaScript-Code zu validieren, empfiehlt sich das Werkzeug JSLint. Es zeigt recht restriktiv Verbesserungspotenzial im Quelltext auf und eignet sich daher auch für das Erlernen der Sprache. So weist JSLint auch auf gern gemachte Fehler wie fehlende Gleichheitszeichen in if-Abfragen hin. In Aptana ist JSLint bereits eingebaut und ist nur über die Einstellungen zu aktivieren.

Leistungsträger

Die Performance von JavaScript hat sich in den letzten Jahren stark verbessert, siehe dazu den JavaScript-Benchmark verschiedener Browser bei cnet.co.uk. Die Browser-Engines wurden gehörig optimiert und kompilieren alle Skripte vor der Ausführung. Sollte es dennoch Performance-Engpässe oder Verzögerungen beim Klickverhalten geben, liegt es also eher am eigenen JavaScript-Programmcode. Und den kann man inzwischen ja mit geeigneten Werkzeugen analysieren.

Die nützlichsten Tools für die Performance-Messung von JavaScript kommen derzeit von Google: Über die Entwicklertools erreicht man in Chrome zum Beispiel einen Profiler, der die Komponenten anzeigt, mit deren Berechnung die CPU am meisten beschäftigt war.

Im Beispiel führt die Funktion calc eine Berechnung mit einer neunstelligen Zahl aus – das Resultat ist im Screenshot erkennbar. Neben Name und Zeilennummer wird auch ausgegeben, in welcher Datei die ursächliche Funktion steht. Über einen "Heap Snapshot" kann man sich auch die Belegung im Arbeitsspeicher ausgeben lassen.

Das Plug-in Speed Tracer funktioniert derzeit nur mit der aktuellen Beta-Version von Chrome. Darin werden sowohl die Ladezeit als auch die Ausführungsdauer aller Komponenten grafisch ansprechend dargestellt:

Auch in diesem Beispiel erscheint der Hinweis auf ein langsames JavaScript, allerdings wird nur die Datei und nicht die verantwortliche Funktion genannt.

Beide Tools zeichnen die Aktionen des Nutzers auf, es lassen sich also auch bestimmte Klickfolgen und deren Auswirkungen überprüfen.

Test & Deployment

Oben wurde beschrieben, wie Ant einen optimierten JavaScript-Build erzeugt. Dieser ist natürlich noch auf dem Server zu deployen. Prinzipiell genügt dafür das Kopieren der Dateien ins Doc-Root des Webservers, was über Tools wie Hudson/Jenkins oder Cruise Control automatisierbar ist.

Die eigentliche Entwicklung einer Webanwendung sollte lokal auf dem Entwicklerrechner und nicht etwa per SSH direkt auf dem Server erfolgen. Das bietet unter Eclipse Vorteile wie eine lokale Historie und die einfache Integration einer Versionskontrolle. Auch ein verteiltes Arbeiten mehrerer Teammitglieder an einem Projekt ist nur so praktisch sinnvoll. Dabei hilft ein Tool wie XAMPP, das einen lokalen Apache-HTTP-Server sowie bei Bedarf eine lokale MySQL-Datenbank und FTP-Server mitbringt.

Alle Tests sollten schließlich auf einem Server laufen, der möglichst identisch wie der Live-Server konfiguriert ist. Alle eingesetzten Dienste sowie das Betriebssystem und die Software müssen auf beiden Umgebungen in derselben Version laufen. Der Test-Server sollte weiterhin über das Internet erreichbar sein, damit externe Tester auf die Anwendungen zugreifen können. Da kein Endnutzer die Domain des Test-Servers kennen dürfte, genügt es meist, den Zugang über eine .htaccess-Datei (Apache) zu schützen.

Zusammenfassung

Das objektorientierte JavaScript macht es möglich, ausbaufähige und gut wartbare Webanwendungen zu entwickeln. Die aktuellen Eclipse-IDEs mit ihrem großen Funktionsumfang sowie leistungsfähige Frameworks wie jQuery erleichtern die Arbeit deutlich. Die Entwicklung mit mehreren Klassen erfolgt lokal, während für die Auslieferung alle enthaltenen Skripte über Ant kombiniert und sich mit dem YUICompressor optimieren lassen. Am Ende steht eine leistungsfähige, interaktive Anwendung, die auf einem aktuellen Smartphone genauso funktioniert wie auf PC, Mac und anderen internetfähigen Geräten.

Jan Petzold
arbeitet als Multimediaentwickler für die Deutsche Welle in Berlin. ()