Der Hype um browserseitige Programmierung ebbt nicht ab. Natürlich hatte ich schon JavaScript geschrieben, jQuery verwendet und die Webseiten so lange gedengelt, wie bis sie funktioniert haben, fremden JS-Code gefixt weil der Kollege unabkömmlich in anderen Projekten versenkt wurde oder mich über nicht erwartetes Verhalten des Codes in einem neuen Browser gewundert.

Frontend-Entwicklung als eigene Domaine

Auf die Dauer ist das aber nicht nur unbefriedigend, sondern die wachsende Kommunikation mit den Frontend-Entwicklern erfordert eine tiefer gehende Kenntnis von der Programmierung im Browser. Die Weiterentwicklung in der IT haben den Frontend-Entwickler als vollständige Domaine die letzten Jahre herausgetrieben.

Es ist das Auseinanderentwickeln des klassischen Backends mit Frontend-Anhängsel und der Programmierung im Frontend selbst, die das Backend nur noch als JSON-Datenbelieferung betrachtet. Hier fehlt im alltäglichen Projektbetrieb spürbar eine Vermittlung dieser beiden Seiten. Aus der früheren Anforderung, dass der Frontend-Entwickler die fertige Oberfläche mit CSS und JS noch einmal schön anmalen soll, ist die Abstimmung der beiden Welten über Schnittstellen wie REST, ajax-Call, WebServices geworden.

Projektrisiko – Trennung beider Welten

Oft fehlen Entwickler, welche in beiden Welten zu Hause sind. Die wissen, wann es z. B. notwendig ist, dass man das Backend nicht mit ein und derselben Abfrage lahmlegt, sondern die Antwort cacht. Oder anders herum, die Webservice-Schnittstelle nicht zu fein oder zu grob granuliert, um dem Frontend die Aufrufe und Datenaufbereitung zu vereinfachen. Man kennt die Möglichkeiten und den Impakt von Anforderungen in der jeweils anderen Welt nicht genug.

Hier liegt nicht zuletzt ein größeres Projektrisiko. Der Code funktioniert auf Entwickler-Ebene prinzipiell. Proof of concept ist ok, die Implementierung stabil, der Jenkins ist grün und Sonar meldet keine großen Auffälligkeiten.

Der erste Lasttest

Dann aber kommt der erste Lasttest. Selbstverständlich viel zu spät, kurz vor Auslieferung wird er gemacht, weil dem Kunden die Ergebnisse des Lasttests laut Vertrag zustehen (Augenzwinker). Dann bricht plötzlich die Performance massiv ein und Fehler tauchen auf, die es vorher nicht gab. Dann ist guter Rat im Wortsinn teuer. Erwähnte ich schon, dass das Budget aufgebraucht ist?

Das ist dann genau der Augenblick, in dem sich alle am Code zusammensetzen und das Verhalten auf Backend-, Frontend- und Middelware-Ebene analysieren. Jetzt spricht man sich ab, wundert sich. Man unterhält sich nicht nur formal über die notwendigen Parameter der Schnittstelle, sondern deren Aufbau in die Tiefe, Zeitverhalten, Nebenläufigkeiten (ganz wichtig). Dies hätte eigentlich schon vor Monaten passieren müssen – eigentlich. Nun wird es stressig und wahrscheinlich teuer.

Vermittlungsebene

Es leuchtet jetzt ein. dass man von Anfang an jemanden dabei haben sollte, der sich in beiden Welten gut auskennt. Das sind oft genau die Kollegen, die man bei Problemen gerne befragt und die man hoffentlich jetzt mit hinzuzieht und es schafft, das Verhalten zu stabilisieren.

Das ist auch einer der Gründe gewesen, weswegen ich begonnen habe, mich noch einmal ganz grundsätzlich mit JavaScript resp. ECMAScript zu beschäftigen. Davon abgesehen, dass man sowieso von Zeit zu Zeit eine neue Programmiersprache lernen sollte.

Nach einigem Suchen auf Youtube fand ich folgenden Beitrag ‚JavaScript: Understanding the Weird Parts – The First 3.5 Hours‘. Der erste Teil ist kostenlos und hat mich überzeugt.

Am Ball bleiben heute, heißt sicher auch ein zumindest grundlegendes aber dabei gründliches Verständnis und Handwerk von JavaScript aufzubauen. Dafür habe ich mittelerweile so manche Nachtschicht eingelegt und mir ein paar nützliche Links und Beiträge gesammelt.

Normalerweise nehme ich mir die Spec der Programmiersprache und arbeite sie durch, flankiert von der Analyse eines entsprechend in dieser Sprache geschriebenen Projekts (möglichst ein nicht triviales). Dann bekommt man ein Gefühl dafür, wie die Sprachmittel an einer Problemstellung lebendig eingesetzt werden, was die Pattern sind und wie man Spezialitäten einsetzt.

Das ist für meine aktuellen Nachtschichten ein Vorgehen, was nicht funktioniert. So war ich auf der Suche nach einer Methode z. B. über Video-Beiträge Wissen aufzubauen. Passende Beiträge zu finden ist ein nicht einfaches Unterfangen. JS-Tutorials erschlagen einen alleine von der Anzahl her und sie müssen auch speziell zu den Lernvorlieben und dem aktuellen Wissenstand passen. So sind passt meine kleine Auswahl sicher nicht für jeden, könnte aber ein Einstieg sein.

A re-introduction to JavaScript (JS tutorial) was der Name schon sagt. Stück für Stück kann man in die Tiefe steigen und alt bekanntes neu beleuchten.

Für die meisten ein alter Hut die Talks von Mr. Crockford. Ich habe trotz dessen seine Talks mit großem Gewinn gehört:

• Douglas Crockford: The JavaScript Programming Language
• Douglas Crockford: The Better Parts – JSConfUY 2014

Wie schon in einem anderen Post geschrieben, finde ich folgenden Talk für mich zum Lernen der Basis von JavaScript bisher am Besten. Habe mir auch den gesamten Kurs auf Udemity zugelegt. (Geht man über den Youtube-Link, so erhält man Rabatt, wie auch immer.)

• JavaScript: Understanding the Weird Parts – The First 3.5 Hours

Der Kurs ist sicher langatmig und voller Wiederholungen. Aber Tony Alicea baut das Verständnis von JavaScript und wie es funktioniert ganz elementar auf. Er betont die wichtigen Schritte und erläutert eines um das andere Mal die grundlegenden Zusammenhänge.

Genau das Richtige für das Lernen nachts nach einem arbeitsreichen Tag, wo ständige Wiederholungen die wegdriftende Aufmerksamkeit einfangen 🙂

Type coercion

Von allen Eigenheiten von JS ist mir allerdings coercion die, die sich für mich mit dem meisten Fehlerpotential verbindet. Diese implizite Typumwandlung tätigt JS automatisch für einen selbst nach dem „best guess“. D. h. es wird der Typ und Wert so umgewandelt, wie es in den meisten Fällen als passend angesehen wird.

An solchen Stellen wird mir bewusst, dass man ein ganz klares Verständnis von JavaScript besitzen muss, um zu verstehen, was an solchen Stellen passiert.

name = name || '<default value>'

Der Oder-Operator gibt hier den ersten zu ‚true‘ konvertierbaren Operanden zurück. ‚undefined‘ führt die Coercion auf ‚false‘, damit wird name= '<default value>' ausgeführt. Ist name aber ein definierter Wert, so wird name gleich diesen Werts gesetzt, es sei denn, dieser Wert ist die Null. Dann schlägt unsere kleine Konstruktion hier fehl.

Kennt man solche Pitfalls, programmiert einfach von vornherein anders. Mit coercion hängt auch ein oft genannter Kandidat für Fehler zusammen ‚==‘ vs. ‚===‘. Siehe hierzu z. B.:

• JavaScript Coercion Demystified

Ob solche Effekte und Sprachmittel nun wünschenswert sind oder nicht, ob sie meinen Vorstellungen von einer guten Programmiersprache entsprechen ist ganz unerheblich. Fakt ist: Um Code fixen zu können oder wartbaren Code zu schreiben, muss ich verstehen, wie der Code (in diesem Falle JavaScript), die ausführende Engine und der Gesamt-Kontext wie z. B. ein Browser oder Node.js funktionieren.