Aus der Werkzeugkiste, Teil 3: Oliver Zeigermann

Inhaltsverzeichnis

Nach Philip Ackermann, der die Artikelreihe "Aus der Werkzeugkiste" eröffnete, und Golo Roden stellt nun Oliver Zeigermann anhand von Kategorien wie Codegenerierung, Editor/IDE, Debugging, Codeanalyse, Unit Testing, Integration Testing, Code Coverage, Building, Deployment und Continuous Integration seine präferierten Werkzeuge vor.

Bis vor einigen Jahren hat er hauptsächlich in Java Software geschrieben, dann aber den Eindruck bekommen, dass ohne Verständnis von JavaScript oder wie ein Browser funktioniert kaum eine professionelle Entwicklung für den Browser möglich ist. Damit meint er nicht, dass jede Webanwendung einen hohen JavaScript-Anteil haben muss, sondern dass man diesen nicht von vornherein​ ausschließt, nur weil man diese Technik nicht beherrscht. Mit dieser Geisteshaltung unterstützt er seit einigen Jahren Firmen entweder durch Beratung oder Projektarbeit. Häufig wird in diese Firmen hauptsächlich Java entwickelt. Nun lassen wir aber ihn zu Wort kommen:

Codegenerierung & IDE/Editor

Ich mag keine Codegenerierung und setze sie daher für professionelle Projekte nicht ein. Allerdings kann es beim Ausprobieren einer neuen Technik angenehmen sein, nicht von null starten zu müssen. Für Angular 2.x nutze ich die Angular CLI, mit der ich durch ng new my-app schnell ein neues Projekt erzeugen kann. Für die React-Entwicklung gibt es mit Create React App das entsprechende Kommando create-react-app my-app.

Ich habe lange Zeit Java entwickelt und dabei die Vorzüge einer IDE kennen gelernt. Gerade beim Refactoring oder bei der Codeanalyse (meist: wo wird bestimmter Code verwendet) wird es ohne IDE schwierig. Eclipse hat sich für mich leider im Bereich JavaScript-Entwicklung als untauglich erwiesen, und so bin ich auf IntelliJ IDEA umgestiegen. Gerade wenn man Projekte mit Java- und JavaScript-Anteil hat, gibt es es für mich keine echte Alternative. WebStorm vom selben Hersteller unterstützt kein Java, ist im JavaScript-Bereich aber fast immer eine Nasenlänge voraus. Und so nutze ich auch das.

Visual Studio Code hat sich in letzter Zeit immer mehr zur Alternative gemausert. Insbesondere wenn ich in TypeScript entwickle, macht diese Zwischenform von IDE und Editor am meisten Spaß, da sie das flüssigste Arbeiten erlaubt. Allerdings fehlen mir hier die Analyse- und Refactoring-Möglichkeiten aus IntelliJ und WebStorm.

Debugging & Codeanalyse

Ich nutze ausschließlich den Debugger der Browsers, und wenn ich kann, dann nur den von Chrome. Hier gibt es die meisten Möglichkeiten, und er funktioniert verlässlich. Es nervt mich manchmal, für das Debugging die IDE verlassen zu müssen, aber der Chrome-Debugger ist allen anderen überlegen – in allen IDEs und allen Programmiersprachen, die ich bisher verwendet habe. Da ich meistens entweder von ES6 (mit oder ohne Flow) oder TypeScript übersetze, nutze ich Sourcemaps, damit ich nach wie vor in meinen Sourcen debuggen kann.

Wie erwähnt nutze ich für eine manuelle Codeanalyse meine IDE. In meinen Build-Prozess binde ich aber auch entweder ESLint für ES6 oder Flow-Code oder TSLint für TypeScript als Linter ein. Gerade bei JavaScript und seinen Freiheitsgraden und Fallstricken kann das nützlich sein. Dazu dränge ich bei allen etwas länger lebenden Projekten auf den Einsatz von zusätzlichen Type-Checkern. Das kann entweder TypeScript oder Flow sein. Durch zusätzliche Typeninformationen lässt sich dabei nicht nur ein Check auf Korrektheit verbessern, sondern auch die Unterstützung in der IDE im Bereich Code-Completion, Analyse und Refactoring.

Testing & Code Coverage

Für Unit-Tests nehme ich die Klassiker Mocha, Chai und Sinon. Ich nutze JavaScript hauptsächlich im Frontend. Daher braucht ein größerer Teil meines Codes das DOM des Browsers. Jedoch versuche ich, den UI-Teil, der das DOM nutzt, und andere Logik klar zu trennen und nur den UI-Teil in einem Integrationstest abzudecken. Dazu nutze ich zum Teil mit dem JSDOM eine reine JavaScript-Implementierung des DOM, das einen Test ohne den Browser erlaubt. Sollte das nicht ausreichen oder möchte ich mit konkreten Browsern testen, nutze ich den Test-Runner Karma. Er kann unterschiedliche Browser starten, ihnen Tests zur Ausführung schicken und die Ergebnisse verarbeiten.

Bei allen meinen Versuchen Webanwendungen als Blackbox mit Selenium/Webdriver oder Ähnlichem zu testen kam bisher meist Frust heraus. Der Aufwand ist aus meiner Erfahrung sehr hoch und das Ergebnis äußerst brüchig. Ich traue mich nicht zu sagen, dass ich das generell in keinem Fall mehr tun würde, aber der Nutzen und Sinn durch einen solchen Test müsste schon sehr hoch sein, damit er einen solchen Aufwand rechtfertigen kann.

Beim Thema Code Coverage eignet sich Istanbul besonders gut für Continuous Integration und als Schritt in meiner Build-Pipeline, und dafür verwende ich es auch. Für das interaktive Arbeiten bevorzuge ich Wallaby.js, das allerdings kommerziell und nicht ganz billig ist. Damit kann ich jedoch interaktiv während des Tippens sehen, welcher Teil meines Codes getestet wird und welcher bisher nicht. Dabei kann ich auch sehen, welcher Teil positiv und negativ getestet ist und welche Zweige nicht durchlaufen werden.

Einen dogmatischen Umgang mit Prozenten in der Code Coverage lehne ich ab. Ich nehme die Information eher als eine von vielen auf. Manche Teile müssen sehr gut getestet werden und manche eben nicht. Jeder Test bedeutet Aufwand und kann potenziell beschränken, wie schnell man sich in der Entwicklung bewegen kann. Interessant sind null Prozent Coverage, die mir sagt, hier ist nichts getestet und hundert Prozent, die mir sagt, dass jemand es auf hundert Prozent Code Coverage abgesehen hat.

Build & Deployment

Zum Bauen von JavaScript nehme ich Babel und Webpack. Für TypeScript kommt der TypeScript-Compiler dazu. In die Webpack-Konfiguration übernehme ich auch Linter und Checker und Plug-ins für optimierte Produktions-Builds. Hier reicht mir das UglifyJsPlugin und Loader für die Integration von CSS und Bildern (style-loader, css-loader, file-loader).

Ich nutze weder Grunt noch Gulp, sondern nur npm-Skripte. Sollten diese nicht reichen, verwende ich entweder Node.js-Module, die man von der Kommandozeile ausführen kann, und zur Not schreibe ich etwas Node.js-Code selbst. Außer den beschriebenen Produktions-Builds nutze ich hier nichts Besonderes. Dateien werden per Kommandozeile auf Server geladen.

Werkzeuge wie Jenkins und TeamCity habe ich bereits benutzt, und sie tun ihren Job. Ich bevorzuge allerdings Travis CI, da ich mich mit einer textuellen Konfiguration eher anfreuden kann.

Letzter Tipp

Ich entwickle schon seit über 30 Jahren Software, und je länger ich das tue, desto klarer wird mir: Es gibt für die meisten und wichtigsten Entscheidungen keine Silver Bullets und keine generellen Regeln. Das heißt, ich muss leider den letzten Tipp schuldig bleiben. Allerdings empfehle ich, allzu dogmatischen Empfehlungen skeptisch gegenüberzutreten.

Oliver Zeigermann
ist Entwickler, Architekt, Berater und Coach. Er hat über Jahrzehnte in vielen unterschiedlichen Sprachen und mit vielen Techniken Software entwickelt. In den letzten Jahren hat er bei vielen Projekten mitgearbeitet, die JavaScript im Browser verwenden. (ane)