Seite 2: Was bedeutet eine gute Developer Experience für mich?

Inhaltsverzeichnis

Für mich persönlich bedeutet eine gute Developer Experience hauptsächlich, stets möglichst schnelle Feedbackschleifen zu haben – also bei allem, was ich tue, möglichst früh Rückmeldung zu bekommen, ob das Getane in Ordnung ist.

Auf technischer Ebene bedeutet das das schnellstmögliche Widerspiegeln der programmierten Änderungen in der laufenden Software. Dadurch kommen mögliche Unstimmigkeiten rasch ans Licht. Je kleiner der Zeitraum ist, der zwischen dem Einbauen und dem Erkennen eines Fehlers liegt, desto besser. Idealerweise weist die IDE ihre Nutzer direkt beim Tippen auf Fehler hin, beispielsweise durch einen eingebundenen Linter. An zweiter Stelle zu nennen sind Ungereimtheiten, die beim Kompilieren zutage treten. Das erlaubt immer noch ein direktes Reagieren, bevor die Anwendung überhaupt gestartet ist. Fehler, die wiederum erst zur Laufzeit der Applikation auffallen, haben die langsamste Feedbackschleife.

Auf organisatorischer Ebene bedeutet das im Idealfall ein frühzeitiges und häufiges Feedback der Endnutzer der Anwendung. So können sie stets auf die tatsächlichen Anforderungen der Kunden eingehen und frühzeitig auf Änderungen reagieren. In der Praxis hat mir frühes und häufiges Fragen nach Feedback schon oft dabei geholfen, schneller zu dem von Kunden gewünschten Ergebnis zu kommen. Ein Beispiel: Bei der Implementierung einer React-Komponente sah die Spezifikation ein Eingabefeld mit besonders komplexer Validierungslogik vor. Es stellte sich aber heraus, dass der Kunde dieses Feld gar nicht brauchte. Hätte ich nicht nach der Implementierung des Minimal-Prototyps um Feedback gebeten, so hätte ich viel Zeit für die Entwicklung der gar nicht benötigten Validierung verschwendet.

Mit dem Code experimentieren und Fehler finden

Zu einer guten Developer Experience gehört für mich außerdem, dass es einfach ist, in und mit dem existierenden Code zu experimentieren. Auch das läuft auf eine höhere Geschwindigkeit der Feedbackschleife hinaus, da für Experimente nicht zwingend erst wieder ein neues Projekt aufzusetzen ist.

Des Weiteren ist es wichtig, dass sich die Suche nach Fehlern so einfach wie möglich gestaltet (das tatsächliche Auffinden ist wiederum ein anderes Thema). Das bedeutet, dass die Anwendung einfach zu debuggen und während der Laufzeit zu untersuchen sein sollte.

Ich möchte möglichst effizient arbeiten und es vermeiden, Zeit mit repetitiven Aufgaben zu vergeuden. Deshalb zählen für mich auch eine gute Autocomplete-Funktionalität und andere Convenience-Features, die viele moderne IDEs mit sich bringen, zu einer guten Developer Experience. Es gehört ebenfalls dazu, sich als professioneller Softwareentwickler oder -entwicklerin an den gegebenen Werkzeugen zu bedienen, also die oben genannten Features tatsächlich effizient zu nutzen.

Der letzte wichtige Punkt für eine gute Developer Experience ist, dass man so wenig Zeit wie möglich für die eher “nervigen” Teile des Programmierens aufwenden muss. Dazu zählen die Formatierung des Quellcodes, Aufräumarbeiten wie das Entfernen ungenutzter Variablen und das Organisieren von Import-Befehlen sowie das Projekt-Setup und die Konfiguration. Die Formatierung und die Aufräumarbeiten sollten idealerweise vollständig automatisiert ablaufen, das Projekt-Setup und das Konfigurieren sind soweit wie möglich durch sinnvolle und direkt nutzbare Standardwerte zu verkürzen.

Geschicktes Auswählen der Programmiersprache

Während sich auf der organisatorischen Ebene allein durch die Wahl des Toolings nur wenig erreichen lässt, können Entwicklerinnen und Entwickler sich in den anderen oben genannten Punkten mit gutem Werkzeug und der Wahl einer geeigneten Programmiersprache durchaus selbst zu einer besseren Developer Experience verhelfen.

Im JavaScript- und TypeScript-Ökosystem gibt es einige Ansatzpunkte, um sich das Leben ein bisschen zu erleichtern, wie beispielsweise die Nutzung von TypeScript anstelle von JavaScript. Die durch TypeScript sichergestellte Typsicherheit und die IDE- und Editor-Unterstützung durch Visual Studio Code oder WebStorm beschleunigen die Feedbackschleife. Viele JavaScript-typische Fehler wie der Attributzugriff auf einen undefined- beziehungsweise null-Wert lassen sich direkt beim Tippen oder Kompilieren erkennen und frühzeitig beheben.

Feedbackschleife beschleunigen

Auch die Verwendung eines Live-Reload-Tools beschleunigt die Feedbackschleife. Es erkennt alle Änderungen am Quellcode automatisch und startet die Anwendung selbstständig neu, sodass die Änderungen direkt in der neu gestarteten Anwendung widergespiegelt sind. Live-Reload-Tools gibt es für browserseitige Anwendungen sowie für serverseitige Anwendungen. Außerdem ist in vielen Testframeworks wie beispielsweise jest oder mocha eine Live-Reload-Funktion eingebaut. Bei der browserseitigen Anwendungsentwicklung bedeutet ein Live Reload, dass sich die im Browser geöffnete Website automatisch aktualisiert, sobald eine Datei mit Änderungen gespeichert wird. Dadurch lassen sich Änderungen direkt auf der Website visualisieren. Bei serverseitiger Entwicklung startet sich die laufende Anwendung automatisch neu, wenn eine Datei verändert wird. So lassen sich unter anderem neu hinzugekommene Endpunkte direkt über ein API-Client-Tool wie Insomnia oder Postman testen.

Um schnell mit dem existierenden Code zu experimentieren, eignen sich die Chrome-Entwicklerkonsole und die Node REPL (read–eval–print loop). Beide sind einfach und schnell zugänglich: Das Öffnen der Node REPL erfolgt über den Befehl node in der Kommandozeile, das Öffnen der Chrome Developer Console über den systemabhängigen Shortcut wie beispielsweise Strg + Shift + J unter Windows. Beide Tools sind nützlich, um kleine Experimente oder Scripts auszuprobieren, ohne gleich neue Dateien oder Projekte erstellen zu müssen.

Die Anwendung anhalten durch Breakpoints

Auch die Nutzung eines Debuggers kann die Feedbackschleife beschleunigen, da er das Anhalten der Anwendung an beliebiger Stelle durch die Nutzung von Breakpoints erlaubt. Des Weiteren ermöglicht er das Untersuchen des Anwendungszustands und der im Quellcode gesetzten Variablen zur Laufzeit. Durch die Kombination eines Debuggers und der oben genannten Entwicklerkonsole lassen sich außerdem Experimente oder Skripte auf zur Laufzeit gesetzten Variablen ausführen. Für serverseitige Anwendungen kommen beispielsweise Visual Studio Code oder WebStorm als IDE mit eingebautem Debugger in Frage. Für browserseitige Anwendungen bieten alle gängigen Browser wie Chrome oder Firefox einen eingebauten Debugger an.

Um den Anteil der ungeliebten Routineaufgaben beim Programmieren so gering wie möglich zu halten, kommen außerdem Tools für automatisierte Formatierung und automatisiertes Linting in Betracht. Ein Linter sorgt automatisch dafür, dass gewisse Formatierungs- und Code-Style-Regeln wie eine Einrückung oder maximale Zeilenbreite eingehalten werden. Er untersucht und analysiert Code, um auf potenzielle Fehler oder Unreinheiten ("unclean code") aufmerksam zu machen und bezieht sich dabei immer auf einen Satz an vorgegebenen Regeln, die er beachtet. Zwei Beispiele für solche Regeln wären: “Es darf kein Code in einer Quelldatei vorhanden sein, der nie erreicht werden kann” oder “Es muss immer === anstelle von == bei Vergleichen genutzt werden”.

Ein beliebtes Code-Formatierungstool im JavaScript-Ökosystem ist Prettier: Es ist mit Standardregeln vorkonfiguriert, die Konfiguration lässt sich aber auch beliebig anpassen. Der De-facto-Standard für Linting im JS-Universum ist ESLint. Wie Prettier kennt es viele Standardregeln und verfügt für verschiedene Projektarten über einen Satz an projektspezifischen Zusatzregeln. Auch hier lassen sich die Einstellungen beliebig verändern.