zurück zum Artikel

In einer neuen Interview-Reihe gewähren Entwickler heise Developer einen Einblick in ihre Toolsammlung. Den Anfang macht Softwareentwickler Philip Ackermann.

Welche Tools Entwickler für ihre Projekte nutzen, verrät einiges über ihre Arbeitsweise und Einstellung: Muss es vi fürs Coden sein oder darf Visual Studio Hilfestellungen zur Fehlervermeidung geben? Investiert man eher Geld in proprietäre Werkzeuge oder Zeit, um an der Verbesserung von Open-Source-Projekten mitzuwirken? Aber auch die bevorzugte Programmiersprache und die Art der Projekte beeinflussen die Toolwahl.

In der neuen Reihe "Aus der Werkzeugkiste" bittet heise Developer Entwickler, anhand der zehn Kategorien Codegenerierung, Editor/IDE, Debugging, Codeanalyse, Unit Testing, Integration Testing, Code Coverage, Building, Deployment und Continuous Integration einen Blick in ihre persönliche Werkzeugkiste zu gewähren. Den Anfang macht unser Blogger Philip Ackermann [1]. Er ist vor allem als Entwickler unter Node.js unterwegs, seine Wurzeln liegen jedoch in der Java-Programmierung. Sein Entwicklerteam beim Fraunhofer-Institut für Angewandte Informationstechnologie arbeitet derzeit an Tools zum teilautomatisierten Testen von Web Compliance sowie den Bereichen eHealth und IoT.

1. Codegenerierung

"Für das Generieren von Codegerüsten oder initialen Projektstrukturen habe ich in der Vergangenheit meistens Yeoman [2] verwendet. Das Tool kann viel mehr als ein einfacher Projektgenerator und hat das allgemeine Ziel, den Workflow beim Entwickeln von JavaScript-Anwendungen zu vereinheitlichen.

Yeoman nimmt Grunt [3] als Build-Tool und Bower [4] als Package Manager zur Grundlage und lässt sich über den Node Package Manager als Node.js-Modul installieren. Das Erzeugen der Projektgerüste wiederum übernehmen sogenannte Generatoren. Mit ihrer Hilfe lassen sich beispielsweise Projektstrukturen für AngularJS [5]-, Spring-Boot/AngularJS [6]-, WordPress [7]-Projekte et ceterea generieren.

Allerdings empfinde ich die Anzahl und den Umfang der erzeugten Artefakte je nach verwendetem Generator teils als zu groß. Darum sind wir in unserem Team nun verstärkt dazu übergegangen, für unterschiedliche Anwendungsfälle (mobile App, Express nutzende Webanwendung etc.) unsere Projektvorlagen in Form von Git-Repositories vorzuhalten und sie bei Bedarf zu klonen. So sind wir eher der Herr über den Quelltext."

2. Editor/IDE

"Da ich ursprünglich aus der Java-Entwicklung komme, wo ich nach wie vor Eclipse [8] als Entwicklungsumgebung verwende, war es am Anfang naheliegend, die IDE auch für die JavaScript-Programmierung zu nutzen. Das erwies sich aber als nicht zufriedenstellend, sodass ich schließlich irgendwann zu JetBrains' WebStorm [9] gewechselt und damit nun sehr zufrieden bin.

Bezüglich der Entwicklung von JavaScript-Anwendungen – egal ob für Node.js, AngularJS oder PhoneGap – ist WebStorm unter den bekannten IDEs für mich am ausgereiftesten (wobei ich fairerweise sagen muss, dass ich NetBeans, was ja in dieser Hinsicht auch ganz gut sein soll, noch nicht über einen längeren Zeitraum hinweg genutzt habe).

WebStorm verfügt über eine Codevervollständigung, die wirklich funktioniert, einen integrierten Debugger, die Möglichkeit, Unit-Tests auszuführen, Integration von Tools zum Überprüfen der Codequalität wie ESLint, Integration von Build-Tools wie Gulp und Grunt, unterschiedliche Projektvorlagen, Git-Integration und vieles mehr. Das sind sind alles Punkte, die ich von einer guten IDE erwarte. Und wenn ich dann mal doch einen Editor brauche, der etwas flotter ist, greife ich auf Sublime Text [10] zurück."

3. Debugging

"Welches Debugging-Tool ich verwende, hängt vor allem davon ab, welche Art von JavaScript-Anwendung ich gerade entwickele.

Für das Debugging grafischer Oberflächen hat sich beispielsweise der Einsatz der Chrome Developer Tools bewährt. Vor kurzem habe ich etwa eine mobile Anwendung auf Basis von PhoneGap [11] programmiert, die per Bluetooth Low Energy (BLE) unterschiedliche Informationen von Estimote [12] Beacons ausliest. Da ist es dann schon sehr nützlich, wenn man mit den Chrome Developer Tools auf den Inhalt des angeschlossenen (Android-)Smartphones zugreifen kann, beispielsweise um den DOM-Baum einzusehen oder über die Entwicklerkonsole JavaScript-Code auszuführen (in dem Fall die BLE-Funktionen anzustoßen).

Für das Debugging von Node.js-Anwendungen verwende ich hingegen die Debugging-Funktionen, die WebStorm mit sich bringt. Geht es darum, Fehler in AngularJS-Anwendungen zu finden, habe ich auch schon auf Angular Batarang [13] zurückgegriffen. Das ist eine Erweiterung für Chrome, die sich in dessen Developer Tools einklinkt und beispielsweise einen Überblick über die jeweiligen Scopes der Anwendung gibt."

4. Codeanalyse

"Für die Analyse von Code beziehungsweise dessen Qualität verwende ich ESLint [14], da es um einiges flexibler und anpassbarer als JSHint [15], JSLint [16], JSBeautifier [17] oder auch der Closure Linter [18] ist. Letztere lassen sich nur relativ eingeschränkt den eigenen Wünschen und Vorstellungen von sauberem Code anpassen: JSLint folgt streng den Code Conventions von Douglas Crockford, Closure Linter dem JavaScript Styleguide von Google, und JSHint sowie JSBeautifier bieten ebenfalls nur wenig Anpassungsmöglichkeiten.

ESLint dagegen erlaubt das Implementieren eigener Regeln, die sich während des Linting-Prozesses bei Bedarf dynamisch hinzuladen lassen. Mittlerweile gibt es eine recht beachtliche Menge solcher Prüfregeln [19], eingeteilt in die Kategorien Fehlervermeidung, Best Practices, Strict-Mode, Variablendeklarationen, Node.js, Stilistik und ECMAScript 6.

Ebenfalls praktisch: ESLint lässt sich (wie allerdings die meisten der anderen genannten Linting-Tools) in die WebStorm-IDE integrieren, sodass die Linting-Regeln direkt während der Entwicklung und nicht erst im Build-Prozess zum Einsatz kommen."

5. Unit Testing

"In Sachen Unit Testing verwende ich im Wesentlichen zwei Tools: für das Testen im Browser QUnit [20], ansonsten Mocha [21]. QUnit wurde von John Resig als Teil der jQuery-Bibliothek entwickelt, hauptsächlich mit dem Ziel, den internen Code von jQuery selbst testen zu können. Im Laufe der Jahre wurden dann die Abhängigkeiten zu jQuery vollständig aufgelöst, sodass QUnit heute universell einsetzbar ist. Dabei lässt es sich sowohl für das Testen von clientseitigem als auch von serverseitigem JavaScript-Code nutzen.

Mocha dagegen ist ein Test-Framework, das aus dem Node.js-Umfeld kommt und sich unabhängig von der Laufzeitumgebung (Browser, Node.js) einsetzen lässt. Es unterscheidet sich von QUnit im Wesentlichen in zwei Punkten: Zum einen enthält es keine Assertion-Funktion, das heißt, man muss dafür zusätzlich eine externe Bibliothek wie should.js [22], expect.js [23] oder chai.js [24] einbinden. Zum anderen lassen sich die einzelnen Testfälle wahlweise in TDD- (wie in QUnit) oder in sogenannter BDD-Schreibweise (Behaviour Driven Development) formulieren.

Beide Tools lassen sich zudem in WebStorm integrieren beziehungsweise sind dort bereits eingebaut. Außerdem ist über entsprechende Plug-ins eine Integration in die beiden Build-Tools Grunt und Gulp möglich."

Integration Testing bis CI

6. Integration Testing

"Beim Thema Integration Testing steht in unserem Team nach wie vor das Selenium-Framework an erster Stelle, genauer gesagt Selenium 2.0 [25], das im Unterschied zur ersten Version des Frameworks auch die sogenannte Web Driver API [26] implementiert.

Mit Hilfe des Node.js-Modules webdriverio [27] können wir Selenium 2.0 sogar unter Node.js nutzen. In Kombination mit dem Node.js-Module webdrivercss [28] lassen sich zudem relativ einfach und automatisch visuelle Regressionstests durchführen, bei denen Entwickler zwei Snapshots einer Webseite auf ungewollte, durch Änderungen am CSS ausgelöste Layout-Abweichungen untersuchen können.

Auf meiner Liste der "Frameworks, die ich mir angucken möchte" steht gerade außerdem Nightwatch.js [29]. Es ist ebenfalls für Integrationstests interessant und nutzt auch Selenium 2.0 als Basis.

Ansonsten habe ich derartige Regressions- und Integrationstests aber auch schon direkt mit PhantomJS [30] geschrieben. Das ist zwar oft mühsamer, funktioniert aber für einfache Tests. Für das Prüfen von AngularJS-Anwendung bietet sich dagegen das projekteigene Protractor [31] an."

7. Code Coverage

"Bezüglich der Testabdeckung habe ich anfangs relativ viel herumprobiert und unterschiedliche Bibliotheken getestet. Letztlich bin ich bei Blanket.js [32] hängengeblieben, weil es sich vergleichsweise unkompliziert und ohne viel Konfigurationsaufwand in Testframeworks wie QUnit, Jasmine [33] und Mocha integrieren lässt.

Um Blanket.js mit QUnit verwenden zu können, muss man lediglich die entsprechende Quelltextdatei von der Blanket.js-Webseite herunterladen und in den QUnit-Testrunner einbinden. Möchte man Blanket.js in Kombination mit Mocha einsetzen, lässt es sich über npm innerhalb des entsprechenden Projekts installieren (npm install blanket). Anschließend kann es über require('blanket')() in den jeweiligen Test eingebunden und direkt aufgerufen werden. Darüber hinaus lässt sich Blanket.js über entsprechende Plug-ins ebenfalls in die Build-Tools Grunt (z.B. über grunt-blanket [34]) und Gulp (z.B. über gulp-blanket-mocha [35]) integrieren.

Im Team dagegen verwenden wir für die Testabdeckung mittlerweile das Tool Istanbul [36], das sich dank Clover-konformen Reports nahtlos in unseren CI-Server einfügt."

8. Building

"Für das Building verwendet unser Team in schätzungsweise 80 Prozent der JavaScript-Projekte Grunt [37] und für die restlichen 20 Gulp [38]. Bezüglich der Definition und Konfiguration von Tasks verfolgt Grunt ja bekanntermaßen den "Configuration over Code"-Ansatz, neigt aber dadurch auch zu aufgeblähten, sehr langen Konfigurationen. Gulp hingegen ist durch seinen "Code over Configuration"-Ansatz leserlicher.

Für neue Projekte verwenden wir daher meist Gulp und haben das mittelfristige Ziel, auch die "alten" Grunt-Projekte entsprechend anzupassen. Allerdings hat das eine vergleichbar geringe Priorität, zumal wir auch bei den Grunt-Konfigurationen immer darauf geachtet haben, dass sie nicht ausarten.

Nicht empfehlen kann ich übrigens, JavaScript-Projekte mit Ant oder Maven zu bauen. Die entsprechenden Plug-ins, die ich mir vor einigen Jahren diesbezüglich einmal angeschaut hatte, waren alles andere als einfach zu konfigurieren. Es kann zwar sein, dass sich da in den letzten Jahren etwas verbessert hat, aber ich würde in Projekten, in denen sowohl Java- als auch JavaScript-Komponenten zu entwickeln sind, das Building dementsprechend aufteilen, also Java-Komponenten mit Ant oder Maven und JavaScript-Komponenten mit Gulp oder Grunt bauen."

9. Deployment

"Für das Deployment kommen bei uns meistens individuelle Grunt- oder Gulp-Skripte zum Einsatz. Mit ihrer Hilfe lassen sich dann zum Beispiel Sass-Daten in CSS umwandeln, HTML,- CSS- und JavaScript-Dateien minifizieren, JavaScript-Code, der in ES6/ES2015 geschrieben ist, bei Bedarf in ES5-kompatiblen Code umwandeln, Bilddateien komprimieren oder in unterschiedlichen Auflösungen generieren und vieles andere mehr. Auf die Uglifier-Funktionen von Tools wie YUI Compressor [39], UglifyJS2 [40] oder Google Closure Compiler [41], die beispielsweise Variablennamen ersetzen, verzichten wir dagegen.

Außerdem achten wir bei Node.js-Modulen stark darauf, dass sich jedes Modul über npm install vollständig installieren lässt. Das funktioniert mittlerweile dank entsprechender npm-Updates auch für Abhängigkeiten, die auf privaten Git-Servern liegen. Auf die Weise können wir auch interne Bibliotheken und Ähnliches vollständig mit npm verwalten und müssen nicht mit eigenen Skripten nachhelfen. Und ja: Docker steht ebenfalls auf der Liste der coolen neuen Techniken, die ich mir in dem Zusammenhang noch angucken möchte."

10. Continuous Integration

"Für Continuous Integration verwenden wir im Team den aus dem Java-Umfeld bekannten CI-Server Jenkins [42]. Ein in dem Zusammenhang besonders nützliches Tool ist, wie ich finde, das Grunt-Plug-in grunt-jenkins [43]. Mit ihm lassen sich Jenkins-Jobs in Form von XML-Konfigurationsdateien vom Jenkins-Server herunterladen, lokal aktualisieren und anschließend wieder auf den Jenkins-Server hochladen. Insbesondere wenn man es mit vielen Jenkins-Jobs zu tun hat, erleichtert das die Verwaltung erheblich.

Für alle unsere Projekte haben wir spezielle Grunt- oder Gulp-Tasks, die das System auf dem Jenkins-Server anstößt, um Unit-Tests auszuführen, die Testabdeckung zu ermitteln, den Code-Style zu überprüfen und/oder Distributionen zu erzeugen.

Externe Jenkins-Plug-ins, die in dem Zusammenhang beispielsweise zum Einsatz kommen, sind das NodeJS-Plug-in [44] für die Integration von Node.js, das Checkstyle-Plug-in [45] für die Code-Analyse über Checkstyle [46], das Clover-Plug-in [47] für das Erzeugen von Code-Coverage-Reports via Clover, das GitHub-Plug-in [48] für das Verbinden zu GitHub und das Bulk-Builder-Plug-in [49] für das einfache Konfigurieren zusammengehöriger Builds."

Letzter Tipp

"Bei all den vielen Bibliotheken, Frameworks und Tools, die es gerade im Bereich der JavaScript-Entwicklung gibt, sollte man sich von der Fülle nicht allzu sehr ablenken lassen. Ich finde es wichtiger und für den Programmieralltag effektiver, einige wenige Frameworks richtig zu beherrschen, statt sich alle paar Tage auf ein neues zu stürzen. Die JavaScript-Community macht es einem da sicherlich nicht leicht, mit all den Dingen, die täglich per Twitter und auf anderen Kanälen teils ungefiltert auf einen einwirken: neues Framework hier, neues Tool da. Und alle machen es besser als die bisherigen.

Klar sollte man hier und da über den Tellerrand schauen, bestehende Frameworks hinterfragen und neuen Tools eine Chance geben. Aber hier gilt meiner Meinung: nicht zu viel Zeit damit verbringen und sich wie gesagt nicht verwirren lassen. Unterm Strich zählt es doch, möglichst effektiv Anwendungen zu entwickeln. Ob ich das dann mit AngularJS oder mit React mache, ist eine Art Glaubensfrage und eine Sache des persönlichen Geschmacks."

Philip Ackermann
entwickelt seit 15 Jahren Web- und Softwareanwendungen, arbeitet beim Fraunhofer-Institut für Angewandte Informationstechnologie FIT im Bereich Web Compliance und eHealth und ist Autor zweier Fachbücher über Java und JavaScript sowie mehrerer Fachartikel. Sein nächstes Buch erscheint im Sommer 2016. (jul [50])

URL dieses Artikels:
https://www.heise.de/-3215454

Links in diesem Artikel:
[1] http://www.heise.de/developer/Tales_from_the_Web_side-2548664.html
[2] http://yeoman.io/
[3] http://gruntjs.com
[4] http://bower.io/
[5] https://github.com/yeoman/generator-angular
[6] https://github.com/jhipster/generator-jhipster
[7] https://github.com/wesleytodd/YeoPress
[8] https://eclipse.org/
[9] https://www.jetbrains.com/webstorm/
[10] https://www.sublimetext.com/
[11] http://phonegap.com/
[12] http://estimote.com
[13] https://github.com/angular/batarang
[14] http://eslint.org/
[15] http://jshint.com/
[16] http://www.jslint.com/
[17] http://jsbeautifier.org/
[18] https://developers.google.com/closure/utilities/
[19] http://eslint.org/docs/rules/
[20] http://qunitjs.com/
[21] http://mochajs.org/
[22] https://github.com/shouldjs/should.js
[23] https://github.com/LearnBoost/expect.js
[24] http://chaijs.com/
[25] http://www.seleniumhq.org/
[26] http://www.w3.org/TR/webdriver/
[27] http://webdriver.io/
[28] https://github.com/webdriverio/webdrivercss
[29] http://nightwatchjs.org/
[30] http://phantomjs.org/
[31] https://github.com/angular/protractor
[32] http://blanketjs.org/
[33] http://jasmine.github.io/
[34] https://github.com/alex-seville/grunt-blanket
[35] https://github.com/dylanb/gulp-blanket-mocha
[36] https://github.com/gotwarlost/istanbul
[37] http://gruntjs.com/
[38] http://gulpjs.com/
[39] http://yui.github.io/yuicompressor/
[40] https://github.com/mishoo/UglifyJS2
[41] https://github.com/google/closure-compiler
[42] https://jenkins.io/
[43] https://github.com/sghill/grunt-jenkins
[44] https://wiki.jenkins-ci.org/display/JENKINS/NodeJS+Plugin
[45] https://wiki.jenkins-ci.org/display/JENKINS/Checkstyle+Plugin
[46] http://checkstyle.sourceforge.net/
[47] https://de.atlassian.com/software/clover
[48] https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin
[49] https://wiki.jenkins-ci.org/display/JENKINS/Bulk+Builder+Plugin
[50] mailto:jul@heise.de

Copyright © 2016 Heise Medien