Qualitatives JavaScript

Gute Qualität in JavaScript mit Jenkins und PHPStorm/WebStorm
Kommentare

Professionelle Software kann nur entwickelt werden, wenn schon im Entstehungsprozess auf die Qualität des entwickelten Produkts geachtet wird. Auch JavaScript ist mittlerweile ein elementarer Bestandteil von Webapplikationen, wenn es um businesskritische Logik auf Clientseite geht. Aus diesem Grund wird es immer wichtiger, auch auf die Qualität im JavaScript-Quellcode zu achten. Im Folgenden werden eine Reihe von Werkzeugen vorgestellt, die einem Entwickler die Arbeit dabei erheblich erleichtern.

PHP Magazin

Der Artikel „Qualitatives JavaScript“ von Sebastian Springer ist erstmalig erschienen im PHP Magazin 6.2012

Mit der Qualitätssicherung ist es wie mit vielen anderen Themen: Um sie richtig durchführen zu können und den maximalen Nutzen daraus zu ziehen, muss man die Hintergründe verstehen. Wird Qualitätssicherung lediglich durchgeführt, „weil es die anderen ja auch machen“, wird sich mit hoher Wahrscheinlichkeit kein positiver Effekt einstellen, vielmehr wird die Qualitätssicherung den Entwicklern zur Last fallen und früher oder später wieder aufgegeben.

Was ist Qualitätssicherung?

Die erste Frage, die in diesem Zusammenhang beantwortet werden muss, lautet: Warum sollte man Qualitätssicherung durchführen? JavaScript ist in den Maßstäben des Internets mittlerweile eine alte Sprache, es existiert seit 1995, damals noch als „LiveScript“. Seit diesen Anfängen wird JavaScript häufig dazu eingesetzt, sehr schnell visuelle Ergebnisse im Browser zu erzeugen. Diese Möglichkeit, sehr schnell Vorzeigbares zu produzieren, hat dazu geführt, dass in JavaScript häufig nach dem Motto „quick and dirty“ vorgegangen wird. In Wahrheit sind die Ergebnisse hier allerdings nur sehr kurzlebig und der anfängliche Geschwindigkeitsvorteil stellt sich sehr bald als Nachteil heraus. Bei der Entwicklung mit JavaScript sollte wie bei anderen Sprachen auf einige Dinge geachtet werden. Das sind im Einzelnen: Stabilität, Erweiterbarkeit und Einfachheit.

Stabilität in Anwendungen beschreibt, wie robust die Software gegenüber Interaktionen ist. Eine stabile Software kann mit fehlerhafter oder falscher Benutzung umgehen. Hierunter fällt im JavaScript-Kontext beispielsweise: Was passiert, wenn ein Benutzer zweimal schnell hintereinander auf einen Button zum Abschicken eines Formulars klickt? Werden zwei Ajax Requests an das Backend abgesendet und führen diese dazu, dass zwei Datensätze erstellt werden?

Erweiterbarkeit bedeutet, dass die Software nicht nur die ursprünglichen Anforderungen erfüllen kann, sondern die Entwickler auch zukünftige oder aber geänderte Anforderungen umsetzen können. Nach dem Quick-and-dirty-Ansatz müsste man hier sagen: „Zusätzliche Features kann man doch immer irgendwie einbauen“. Eine Anforderung, die mit der Erweiterbarkeit einhergeht, ist allerdings, dass die Erweiterungen möglichst preiswert umgesetzt werden können. Dabei ist zu berücksichtigen, zu welchem Zeitpunkt im Softwarelebenszyklus ein bestimmtes Feature oder ein Bug auftritt. Je später dies der Fall ist, also je fixierter die Anwendung ist, umso größer wird der Aufwand. Durch Maßnahmen der Qualitätssicherung können die Kosten der Erweiterung oder Fehlerbeseitigung allerdings signifikant gesenkt werden. So kann beispielsweise sichergestellt werden, dass durch eine Änderung an einer Stelle keine andere Funktionalität an einer anderen Stelle in der Software negativ beeinflusst wird.

Einfachheit von Quellcode und damit einer Anwendung zeichnet sich nicht dadurch aus, dass die „bells and whistles“, die eine Anwendung für den Nutzer attraktiv machen, nicht umgesetzt werden können, weil sie eben nicht einfach sind. Einfachheit bezieht sich vielmehr auf die einfachste technische Umsetzung eines Features. Ein Entwickler sollte sich immer die Frage stellen: Was will ich mit meiner aktuellen Aufgabe erreichen und welcher Quellcode ist dafür notwendig? Eine Anforderung sollte stets auf möglichst direktem und technisch solidem Weg umgesetzt werden. Das verhindert, dass der Quellcode unnötig komplex wird. Die unnötige Komplexität von Software ist ein großes Problem, wenn es sich um langlebige Software handelt, die über ihren gesamten Lebenszyklus erweitert werden soll oder wenn sich das Team über die Projektlaufzeit ändert und Entwickler es verlassen und neue Personen hinzukommen, die erst in den bestehenden Quellcode eingearbeitet werden müssen.

Was haben diese Punkte nun mit Qualitätssicherung zu tun? Die vorgestellten Punkte sind die Basis von professioneller Software, und sie lassen sich nur nachhaltig durch eine funktionierende Qualitätssicherung erreichen.

Continuous Integration und Continuous Inspection

Continuous Integration und Continuous Inspection bilden die Basis für eine flexible und gesicherte Softwareentwicklung. Beide Praktiken haben in anderen Sprachen wie Java oder PHP schon lange Einzug gehalten. Aber auch im JavaScript-Umfeld gewinnt die kontinuierliche Qualitätssicherung immer mehr an Bedeutung.

Continuous Integration bezeichnet die Integration einzelner Bestandteile oder Module einer Applikation in das Gesamtsystem. Den Hintergrund dazu bildet die Idee, dass ein Entwickler meist an abgegrenzten Teilen einer Software arbeitet und nicht immer das Gesamtsystem im Blick haben kann, beziehungsweise nicht sämtliche Testfälle bei jeder Änderung prüfen kann. Continuous Integration funktioniert, indem bei jedem Einchecken in das Versionskontrollsystem bestimmte Aktionen wie beispielsweise die automatisierte Ausführung von Tests angestoßen werden. Continuous Integration beschreibt also, wie sich die Software während der Laufzeit verhält.

Continuous Inspection beschäftigt sich mit der Qualität des Quellcodes. Hierbei fällt häufig der Begriff „Technical Debt“. Das sind die technischen Schulden, die im Verlauf der Entwicklung aufgebaut werden. Technische Schulden werden mit jeder zusätzlichen Programmzeile aufgebaut. Jedes Statement im Quellcode erhöht die Komplexität der Anwendung und führt so zu einer Erhöhung der technischen Schulden. Diese Tatsache ist allerdings normal und im Alltag auch unumgänglich. Problematisch wird die Situation erst, wenn übermäßig viele technische Schulden aufgebaut werden. Das ist der Fall, wenn Konventionen oder Standards außer Acht gelassen werden, um ein bestimmtes Ziel wie die Fertigstellung eines Features zu einem bestimmten Zeitpunkt zu erreichen. Je mehr von diesen technischen Schulden aufgebaut werden, desto teurer wird die Entwicklung von neuen Features, aber auch die Behebung bestehender Fehler in der Software, da der Quellcode zunehmend schlechter zu erweitern und zu warten ist. In vielen Projekten hat es sich mittlerweile bewusst etabliert, technische Schulden aufzubauen, diese allerdings später in gezielten Aktionen wieder abzubauen.


Themen der kommenden Seiten:

  • QA-Plattformen
  • Continuous Integration und Versionskontrolle
  • jslint
  • Copy/Paste Detector
  • Unit Tests
  • Fazit
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -