Beim Relaunch der internationalen Plattform radio.net sowie dem dazugehörigen Radio-Aggregator radio.de stand die Überarbeitung des gesamten Stacks an – von Backend und Suche, API und Web-Frontend bis hin zu den mobilen Apps für iOS, Android, Windows Phone und Blackberry.

Um bei einem Projekt dieser Größenordnung eine parallele Entwicklung zu gewährleisten, ist es notwendig, Arbeitspakete und technische Komponenten genau zu analysieren und voneinander zu entkoppeln. Ziel der agilen Entwicklung des Projekts waren deshalb lauffähige Zwischenstände und die Möglichkeit, die geplanten Interaktionsmöglichkeiten jederzeit prüfen zu können.

Unser Team verantwortete die Umsetzung des gesamten Frontends. Dafür gab es drei Hauptanforderungen von Seiten der Auftraggeber:

• Aufbau einzelner Seiten mittels JavaServer Pages (JSP)
• Keine Unterbrechung des radio.de-Players beim Seitenwechsel
• Umsetzung eines modularen, responsiven Designs

Die zentrale Idee der neuen Informationsarchitektur von radio.de ist die Strukturierung in Modulen, aus denen sich die einzelnen Seiten zusammensetzen. Wichtig war es vor allem, dem Kunden gegenüber diese neue Modularisierung von Beginn an zu verdeutlichen. Bei der Erstellung von Wireframes und Layout-Mockups verstehen Kunden die Ergebnisse nämlich oft als in sich abgeschlossene Seiten und weniger als ein System aus Komponenten, dessen einzelne, funktionale Bestandteile auf mehreren Seiten Verwendung finden.

AngularJS setzt wie auch andere JavaScript-Frameworks auf das Konzept DRY (Don’t Repeat Yourself). Es gab uns mit seinem modularisierten Ansatz, der performanten Zwei-Wege-Datenbindung, die im View wie im Model auf Zustandsänderungen reagieren kann, sowie mit den Testmöglichkeiten die nötigen Mittel an die Hand, um die Anforderungen der komplexen UI-Elemente umzusetzen.

Im Vergleich zu Ember.js fallen die Vorgaben für die Strukturierung von Dateien weniger strikt aus. So werden zwar Dateien anhand ihrer Namen im Code erkannt, für die Ordnerstruktur lässt AngularJS aber kompletten Freiraum für eigene Anpassungen.

Eine Vorgabe von radio.de war die Nutzung von JSP für die Ausgabe der Seitentemplates. Da das gesamte Serversystem von radio.de und radio.net in Java implementiert ist, bildeten neben der API die JSP-Templates unsere Schnittstelle zum Backend. Hierdurch konnten wir für die Entwicklung einen Hybrid-Ansatz nutzen. Die auf dem Server generierten Templates dienen der schnellen Rückgabe der initialen Daten. Hier geschehen bereits alle strukturellen Arbeitsschritte: zum einen die für SEO relevante Ausgabe der HTML-Strukturen, zum anderen die Auslagerung des für AngularJS sonst extra anfallenden Pre-Renderings auf Server-Seite.

Der AngularJS-Web-Client setzt auf diese strukturelle Basis auf und fokussiert sich auf die dynamische Anzeige und das Austauschen von Inhalten, ohne Seiten neu laden zu müssen. Durch die MVC-Logik von AngularJS konnten wir so von Beginn an das Verhalten der User-Interface-Komponenten implementieren, auch ohne eine funktionale API.

Die grundlegenden Informationen über die Struktur der API-Callbacks lagen bereits vor und waren definiert. Wir erstellten anhand dieser unsere eigenen Mockdaten, implementierten als Erstes alle Mechanismen zur Anzeige und Verarbeitung von Daten und entkoppelten uns für die interne Entwicklung von Abhängigkeiten zu anderen Dienstleistern.

Zur Code-Versionierung nutzten wir Git, als zentrale Verwaltung die als Open Source kostenfreie GitLab-Community-Edition.

Für die Organisation der Entwicklungs-Branches setzte unser Team auf die Vorgaben der Git-Erweiterung „Git Flow“. Einzelne Arbeitspakete wurden jeweils in einzelnen Feature-Branches angelegt und bearbeitet.

Für die reine Frontend-Entwicklung der Features des AngularJS-Clients kam der Static-Site-Generator Middleman zum Einsatz. Damit liefen auf jedem Entwicklerrechner dieselben Tools und jeder Entwickler konnte unabhängig von den anderen seine Arbeitspakete implementieren und lokal prüfen.

Für jedes Projekt ist eine strukturierte Herangehensweise mit Rücksicht auf die Arbeitsschritte, die eigene Arbeitsorganisation sowie die jeweiligen Projektziele essenziell. Ein reines „Abfeuern” von Tools und Technologien kann nicht funktionieren, wenn sich dies nicht im Projektkontext rechtfertigen lässt und es keinen Mehrwert für alle Beteiligten erzielt.

Für uns funktionierten die bisherigen Tools bei der Nutzung von AngularJS besonders gut. Gleichzeitig erwachte nach der Einarbeitung aller Entwickler auch die Kreativität: Wir passten die Code-Struktur der AngularJS-App unseren Bedürfnissen an, um die Arbeit für alle weiter zu verbessern und die grundlegenden Arbeitsprozesse sowie den Wissenszuwachs in der AngularJS-Entwicklung im Team tiefer zu verwurzeln.

Ein Feature galt als abgeschlossen, wenn ein Kollege jeweils die Komponente des anderen zumindest im Ansatz mit ihm durchgesprochen hat. Hierbei fielen vor allem zu Beginn Unterschiede im Coding-Stil auf. Über den Projektverlauf glich sich dieser durch den regelmäßigen Austausch an. Zudem etablierte sich ein gemeinsames Verständnis von der Gesamtstruktur, etwa wie einzelne Komponenten und Services aufeinander aufbauen und miteinander interagieren, was eine gemeinsame Wissensbasis geschaffen hat.

Die herausgearbeiteten Coding-Standards paarten wir mit klassischen Methoden der Code-Analyse. So nutzten wir Grunt für unseren Build-Prozess zum Kompilieren und Komprimieren aller Sources. Grunt führt darüber hinaus auch eine statische Code-Analyse – das Linting – für den gesamten JavaScript-Code und das SCSS durch, um Fehler im Code aufzuspüren. Damit diese Tasks nicht repetitiv von Hand ausgeführt werden mussten, setzten wir Git-Commit-Hooks, welche die Tasks vor jedem Einchecken ausführten. Bei Fehlern bricht der Checkin mit aussagekräftigen Fehlermeldungen ab. Dank dieses Vorgehens befindet sich ausschließlich syntaktisch korrekter Code in unserem Repository.

Die Aufteilung des Frontends in einzelne Module erleichterte die Zusammenarbeit im Entwicklerteam und ließ sich gut mit AngularJS umsetzen.

Nach Abschluss eines Features wurde der feature-Branch jeweils im develop-Branch zusammengeführt („merged“). Diesen nutzen wir als unseren Integrationsbranch. Hier ließen sich auf einem Preview-Server das Zusammenspiel der Komponenten anschauen und das Zwischenergebnis überprüfen. Der master-Branch wurde von uns für fertige Releases genutzt, die für Deployments beim Kunden entsprechend markiert („tagged“) wurden.

AngularJS folgt nur lose dem Paradigma von „Convention over Configuration“. Wir entschieden uns dazu, komponentenbasiert zu denken, und übertrugen den modularen Aufbau der Seite entsprechend auf die Ordnerstruktur (inspiriert von Cliff Meyers Gegenüberstellung von verschiedenen Organisations-Ansätzen).

Alle Komponenten/Module bekamen eigene Ordner, in denen jeglicher für die Logik verantwortliche Code abgelegt wurde. Die jeweiligen Views lagerten wir gesondert im Ordner „Views” aus. Modulübergreifende Logik legten wir im „common“-Verzeichnis ab. Hier befinden sich zum Beispiel nützliche Tools und Bibliotheken für Angular selbst wie etwa das Tracking-Modul „angulartics“ oder JavaScript-Bibliotheken wie jQuery oder lodash.

.
|—— radioApp.js
|—— common
| |—— controllers.js
| |—— directives.js
| |—— services.js
|—— components
| |—— instantSearch
| | |—— instantSearchController.js
| | |—— instantSearchDirective.js
| | |—— instantSearchService.js
| |—— tracklisting
|   |—— tracklistingController.js
|   |—— tracklistingDirective.js
|—— views
  |—— tracklisting.html

(function (define) {
	"use strict";

	define(function (require) {
		var angular = require('angular');
		...
		// required Directives
		require('common/directives');
		...
		// required Controllers
		require('common/controllers');
		...
		require('components/tracklisting/tracklistingController');
		...
		// required Services
		require('common/services');
		...
		var dependencies = [
			'controllers',
			'services',
			'directives',
			...
		];
		var radioApp = angular.module('radioApp', dependencies);
		...
		return radioApp;
	});
}(define));

(function (define) {
	"use strict";
	define(['angular'], function(angular) {
		return angular.module('controllers', []);
	});
}(define));

(function (define) {
	"use strict";	
	define([
		'common/controllers',
		'components/tracklisting/tracklistingDirective',
		...
	], function (controllers) {
		controllers.controller('tracklistingController', [...], function(...) {
			...
		}]);
	});
}(define));