Aus der Werkzeugkiste, Teil 1: Philip Ackermann

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

In Pocket speichern vorlesen Druckansicht 10 Kommentare lesen
Aus der Werkzeugkiste, Teil 1: Philip Ackermann
Lesezeit: 14 Min.
Von
  • Philip Ackermann
Inhaltsverzeichnis

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.

Philip Ackermann

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. 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.

"Für das Generieren von Codegerüsten oder initialen Projektstrukturen habe ich in der Vergangenheit meistens Yeoman 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 als Build-Tool und Bower 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-, Spring-Boot/AngularJS-, WordPress-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."

"Da ich ursprünglich aus der Java-Entwicklung komme, wo ich nach wie vor Eclipse 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 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 zurück."

"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 programmiert, die per Bluetooth Low Energy (BLE) unterschiedliche Informationen von Estimote 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 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."

"Für die Analyse von Code beziehungsweise dessen Qualität verwende ich ESLint, da es um einiges flexibler und anpassbarer als JSHint, JSLint, JSBeautifier oder auch der Closure Linter 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, 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."

"In Sachen Unit Testing verwende ich im Wesentlichen zwei Tools: für das Testen im Browser QUnit, ansonsten Mocha. 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, expect.js oder chai.js 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."