Aus der Werkzeugkiste, Teil 2: Golo Roden

Inhaltsverzeichnis

Nach Philip Ackermann, der die Interviewreihe "Aus der Werkzeugkiste" eröffnete, stellt nun Golo Roden anhand der zehn Kategorien Codegenerierung, Editor/IDE, Debugging, Codeanalyse, Unit Testing, Integration Testing, Code Coverage, Building, Deployment und Continuous Integration seine Werkzeuge vor. Da beide viel Zeit mit Webentwicklung verbringen, dürfte es spannend sein zu sehen, ob sie auch zu ähnlichen Hilfsmitteln greifen.

Golo Roden ist Mitgründer und CTO der the native web GmbH und hat nach vielen Jahren der C#-Entwicklung seinen Weg zu JavaScript gefunden. Seine besondere Leidenschaft gilt Node.js, wie unter anderem sein Buch zum Thema zeigt. Sein Team entwickelt eine Backend-as-a-Service-Plattform mit Node.js und Go.

1. Codegenerierung

Möchte man eine neue Anwendung oder ein neues Modul erstellen, ist zunächst die Projektstruktur aufzusetzen. Früher habe ich dafür in der Regel grunt-init verwendet, inzwischen erledige ich das eher per Hand.

Das JavaScript- und Node.js-Ökosystem entwickelt sich dermaßen schnell weiter, dass man regelmäßig gezwungen ist, seine Vorlagen zu aktualisieren. Da mir das zu aufwendig und zeitintensiv war, veralteten sie schnell. Daher musste ich die erzeugte Struktur häufig im Nachgang anpassen, was den Sinn einer Vorlage ad absurdum führt.

Das Geheimnis beim Verzicht auf Tools zur Codegenerierung ist, Projekte nicht zu groß werden zu lassen. Für kleine Projekte, die nur aus wenigen Dateien bestehen, lässt sich die Struktur rasch von Hand erstellen. Nebenbei bemerkt ist das mein größter Kritikpunkt an den zahllosen Vorlagen, die man online findet: Sie enthalten zu viel Code, bei dem man nicht genau weiß, was er bewirkt.

Große Anwendungen und Module stellen für mich ein Antipattern dar. Den Bedarf an einem Tool zur Codegenerierung sehe ich daher nicht als Hinweis darauf, dass noch ein Element in der Werkzeugkiste fehlt, sondern als Warnung, dass die Projektstruktur falsch ist und die Entwickler nicht genug über Modularisierung nachgedacht haben.

2. Editor/IDE

Ich entwickle primär mit Node.js und Go. Beiden ist gemein, dass sie eine zügige und leichtgewichtige Programmierung ermöglichen. Beide sind ideal, um eine spontane Idee rasch umzusetzen und auszuprobieren. Dabei soll mich keine große, schwergewichtige IDE bremsen. Stattdessen benötige ich schnelle und schlanke Software, die mir nicht im Weg steht.

Für mich ist daher der von GitHub entwickelte Editor Atom das Werkzeug der Wahl. Er steht kostenlos und quelloffen zur Verfügung, wird von Entwicklern für Entwickler erarbeitet und lässt sich zudem durch zahlreiche Add-ins erweitern und an individuelle Bedürfnisse anpassen. Für JavaScript, Node.js und React setze ich dafür auf linter, linter-eslint und react, für Go ist zudem go-plus installiert. Ergänzt wird das Ganze durch uuidgen, mit dem sich auf Tastendruck UUIDs erzeugen lassen.

Die Entscheidung für einen Editor und gegen eine IDE sorgt oft für Verwunderung bei Entwicklern, die mit anderen Sprachen arbeiten. Für sie ist das Arbeiten ohne IDE unvorstellbar, weil man dann vermeintlich auf die diversen integrierten Hilfsmittel verzichten muss. Das stimmt jedoch nicht: Lediglich der Ort der Integration verschiebt sich vom Editor auf die Kommandozeile, wo Skripte die Aufgabe übernehmen.

Der große Vorteil eines derartigen Vorgehens ist, dass sich die Skripte ohne Anpassung auf einem Server verwenden lassen. Dadurch existiert nur ein einziger Build-Prozess, den Entwickler auf die gleiche Art ausführen können wie der Buildserver. Der häufig gehörten Äußerung "It works on my machine." lässt sich so hervorragend vorbeugen.

Was ich gerne noch lernen möchte, ist der professionelle Umgang mit vi. Der Editor wird zwar gerne als steinzeitlich belächelt, doch wer schon einmal jemandem über die Schulter schauen durfte, der sich mit vi wirklich auskennt, weiß, wie viel schneller man im Vergleich zu anderen Editoren damit arbeiten kann – und erst recht im Vergleich zu einer IDE.

3. Debugging

Nicht nur aufgrund meiner Entscheidung gegen eine IDE begegnen mir viele Entwickler mit Verwunderung. Das gleiche gilt für die Aussage, dass ich generell ohne Debugger arbeite.

Debugger unterstützen Entwickler bei der Analyse komplexer Szenarien. Wie schon bei Werkzeugen zur Codegenerierung sehe ich den Bedarf für einen Debugger als Symptom eines Problems und nicht als Toolmangel.

Der Grund dafür ist, dass ich sehr viel mit testgetriebener Entwicklung arbeite und eine Testabdeckung von 100 Prozent anstrebe. Das gelingt zwar nicht immer, ist für mich aber das erstrebenswerte Ideal. Arbeitet man auf die Art, bemerkt man Fehler extrem früh und kann sie dank der Tests auf einige wenige Zeilen Code eingrenzen.

Zu ihrer Analyse bedarf es keines Debuggers. Der Aufwand, ihn zu starten und an den laufenden Prozess anzuhängen, ist weitaus höher, als einige Aufrufe der Funktion console.log beziehungsweise fmt.Println einzufügen.

4. Codeanalyse

Das Thema Codeanalyse ist mir enorm wichtig. Eines der Ziele unseres Teams ist, dass am Codestil nicht ersichtlich sein soll, welcher Entwickler ihn geschrieben hat. Da die äußere Form auf die Art immer gleich ist, kann man sich schneller mit dem eigentlichen fachlichen Problem beschäftigen und verschwendet keine Zeit darauf, über Formulierungen im Code nachzudenken, die sich syntaktisch zwar unterscheiden, semantisch aber gleichwertig sind.

Als Grundlage dient dafür unter Node.js ESLint, für das unser Team einen sehr strikten Regelsatz entworfen hat. Er steht ebenso wie ESLint quelloffen zur Verfügung. Die zuvor erwähnten Atom-Add-ins linter und linter-eslint sorgen dafür, dass die Codeanalyse während des Schreibens aktiv ist, so dass man sofort Feedback erhält.

Unter Go fällt der Einsatz eines solchen Werkzeugs noch leichter, da Go die wesentlichen Aspekte mit dem Befehl gofmt abdeckt. Atom ruft ihn beim Speichern automatisch auf und formatiert den Code. Zusätzlich lässt sich govet verwenden, um Code nicht nur syntaktisch, sondern auch im Hinblick auf Best Practices überprüfen zu können.

5. Unit Testing

Für das Schreiben von Unit-Tests greife ich unter Node.js auf Mocha zurück. Es lässt sich gut konfigurieren und kommt hervorragend mit asynchronem Code zurecht, was im JavaScript-Kontext besonders wichtig ist.

Um Mocha tatsächlich verwenden zu können, bedarf es zumindest noch eines Assertion-Moduls. Dafür habe ich assertthat geschrieben, das eine durch das .NET-Tool NUnit inspirierte Fluent API bietet, deren Anweisungen sich wie englische Sätze lesen:

assert.that(sum).is.equalTo(23);
 

Zum Testen von HTTP-Servern verwende ich supertest, zum Überprüfen von HTTP-Clients nock. Als allgemeines Mocking-Modul kommt sinon zum Einsatz.

Ergänzt wird das Set-up durch einige Module für Spezialfälle, wie nodeenv zum Kontrollieren von Umgebungsvariablen, isolated zur einfachen Arbeit mit dem Dateisystem und record-stdstreams zum Abfangen des Standardausgabe- und Standardfehlerstroms.

Da Go mit dem Befehl go test ein Hilfsmittel zum Ausführen von Unit-Tests enthält, ist der Bedarf an zusätzlichen Modulen hier geringer. Dennoch verwende ich gelegentlich gocheck, das sich in go test einklinkt und es um einige nützliche Funktionen ergänzt.

Vieles, was unter Node.js mit zusätzlichen Modulen nachzurüsten ist, deckt Go durch die umfangreiche Standardbibliothek ab.