Web-App Entwicklung: Codebasis & JavaScript

Die steigende Anzahl an Plattformen (Android, iOS, Windows, diverse Browser) führt zu hohem Entwicklungsaufwand bei Software. Webtechnologien wie HTML, CSS und JavaScript bieten sich als universelle Lösung an, da sie plattformübergreifend verfügbar sind. Dies ermöglicht Webentwicklern die Erstellung von Anwendungen für verschiedene Plattformen ohne großen zusätzlichen Lernaufwand. Die Nutzung von Webtechnologien und einer gemeinsamen Codebasis soll den Entwicklungs- und Wartungsaufwand für mobile und Web-Anwendungen signifikant reduzieren. Die Arbeit untersucht daher die Möglichkeiten der Cross-Plattform Entwicklung, um diese Effizienzsteigerung zu erreichen und zu bewerten.

Die Arbeit beschreibt verschiedene Ansätze zur Entwicklung mobiler Anwendungen und deren technische Grundlagen. Native Apps, die direkt auf dem Gerät ausgeführt werden und vollen Hardwarezugriff bieten, werden hinsichtlich ihres hohen Entwicklungsaufwands (separate Implementierung für jedes Betriebssystem) beleuchtet. Im Gegensatz dazu werden Hybrid-Apps, die eine Webanwendung in einem nativen Wrapper einbetten, und Progressive Web Apps (PWAs), die sich wie native Apps verhalten, vorgestellt. Die Verwendung von JavaScript-Frameworks, die auf Apache Cordova aufbauen und optimierte UI-Komponenten für mobile Betriebssysteme bereitstellen, wird ebenfalls erörtert. Runtime-basierte Hybrid-Apps, die native UI-Komponenten mit einer JavaScript-Laufzeitumgebung kombinieren, sowie WebView-basierte Hybrid-Apps, die eine Webseite in der Browserengine des Geräts ausführen, werden detailliert beschrieben. Die jeweiligen Vor- und Nachteile dieser Ansätze im Hinblick auf Entwicklungsaufwand und Wartbarkeit werden analysiert.

Der Begriff der Wartbarkeit wird definiert und verschiedene Faktoren, die die Wartbarkeit von Software beeinflussen, werden identifiziert. Dazu gehören Eigenschaften von Programmiersprachen, Konzepte und Methoden der Softwareentwicklung. Die Bedeutung der objektorientierten Programmierung für die Erstellung wartbarer Software wird hervorgehoben. Die Arbeit analysiert die Programmiersprache JavaScript im Hinblick auf ihre Stärken und Schwächen bezüglich Wartbarkeit. Konzepte wie Modularität, die Unterstützung von 'information hiding' (Datenkapselung), Analysierbarkeit (leichtes Verständnis der Struktur und Funktionsweise), Modifizierbarkeit (einfache Anpassung des Codes), Wiederverwendbarkeit (Einsatz von Code in mehreren Systemen) und Testbarkeit (Fehlererkennung durch Codeausführung) werden im Detail untersucht. Die Rolle von expliziten Sprachkonstrukten und deren Auswirkung auf die Wartbarkeit wird diskutiert.

Die Arbeit untersucht JavaScript, eine prototypenbasierte, objektorientierte und interpretierte Sprache mit dynamischen Typprüfungen, im Hinblick auf ihre Eignung für die Erstellung wartbarer Software. Ein zentraler Punkt ist das Fehlen expliziter Sprachkonstrukte für eine klassenbasierte Objektorientierung. Obwohl das Verhalten von Klassen durch Konstruktorfunktionen nachgebildet werden kann, erschwert dies die objektorientierte Programmierung und beeinträchtigt die Wartbarkeit. Gama et al. (2013) und Crockford (2008) werden zitiert, die verschiedene Ansätze zur Simulation klassenbasierter Objektorientierung in JavaScript beschreiben und deren Nachteile für das Programmverständnis und die Wartbarkeit aufzeigen. Die fehlende einheitliche Methode zur Objekterzeugung und die Abwesenheit expliziter Sprachkonstrukte zur Zugriffssteuerung erschweren die Analysierbarkeit und Änderbarkeit des Quellcodes. Die dynamische Natur von JavaScript, die Änderungen von Objektmethoden an beliebigen Stellen im Code zulässt, stellt eine weitere Herausforderung für die Wartbarkeit dar.

Ein wichtiger Aspekt der Analyse ist die Datenkapselung, auch als 'information hiding' bekannt. In Sprachen wie Java existiert das Schlüsselwort 'private' zur expliziten Steuerung des Zugriffs auf Eigenschaften und Methoden. JavaScript bietet kein vergleichbares explizites Konstrukt. Die Umsetzung von Kapselung muss über spezielle Codestrukturen erfolgen, was die Zugriffsbeschränkungen nicht direkt kennzeichnet und zusätzliche Kenntnisse über die Implementierung erfordert. Die mangelnde Unterstützung von Kapselung erschwert die Modularisierung von Software und die Trennung von Schnittstelle und Implementierung. Dies kann zu eng gekoppelten Code-Strukturen führen und Änderungen an einem Modul die Funktionalität anderer Module beeinflussen. Die Bedeutung der Modularität für die Wiederverwendbarkeit und Wartbarkeit wird hervorgehoben. Teßmer (2012) wird zitiert, der die Wichtigkeit der Kapselung für eine modulare Softwarestruktur betont.

Die Arbeit behandelt die Testbarkeit von Software und deren Abhängigkeit von einer angemessenen Modularisierung des Quellcodes. Eine hohe Vererbungstiefe in objektorientierter Programmierung kann die Testbarkeit negativ beeinflussen, da jede Klasse einzeln getestet werden muss. Die Bedeutung automatisierter Tests für umfangreiche Systeme wird hervorgehoben. Der Aspekt der Wiederverwendbarkeit wird im Kontext der ISO/IEC 25010 Definition diskutiert und die Modularität als wesentliche Voraussetzung dafür identifiziert. Szyperski et al. (2003) und Lahres and Raýman (2006c) werden zitiert, die die Bedeutung der Modularisierung für die Wiederverwendbarkeit von Software betonen. Zusammenfassend wird deutlich gemacht, dass die prototypenbasierte Natur von JavaScript, gepaart mit dem Mangel an expliziten Sprachkonstrukten, die Wartbarkeit und Wiederverwendbarkeit von Code herausfordert und somit die Effizienz der Softwareentwicklung beeinträchtigt.

Die Arbeit untersucht die Möglichkeiten zur Verbesserung der Wartbarkeit von JavaScript durch den Einsatz von ECMAScript 2015 (ES6) und TypeScript. TypeScript erweitert die Syntax von ECMAScript 2015 um Sprachkonstrukte für statische Typisierung und Kapselung. Der TypeScript-Compiler führt Prüfungen durch, die viele Fehler bereits während der Übersetzung erkennen lassen. Die Funktionsweise von TypeScript als 'Syntactic Sugar' wird erläutert: die zusätzlichen Funktionen zur Kapselung und statischen Typisierung existieren nur während der Entwicklung, nicht zur Laufzeit. Obwohl der generierte JavaScript-Code nicht um Laufzeit-Sicherheitsmechanismen erweitert wird, wird die positive Kommunikationswirkung expliziter Sprachkonstrukte erreicht, was die Wartbarkeit verbessert. Meyer (1997) wird zitiert, der betont, dass Kapselung nicht auf Geheimhaltung abzielt, sondern auf die Etablierung einer verlässlichen Übereinkunft über den Zugriff auf Variablen und Methoden.

Die Arbeit evaluiert drei JavaScript Frameworks für die Entwicklung von Hybrid Apps: Ionic, NativeScript und React Native. Die Auswahl basiert auf vordefinierten Kriterien, die die Frameworks zwingend erfüllen müssen (Muss-Kriterien) und wünschenswerte Eigenschaften (Soll-Kriterien) umfassen. Zu den Muss-Kriterien gehören die Unterstützung der Plattformen iOS, Android und Webbrowser, die Verfügbarkeit stabiler Versionen und ein Update innerhalb der letzten drei Monate. Frameworks wie Appcelerator Titanium, Xamarin und Flutter wurden aufgrund von Lizenzierungsbeschränkungen, mangelnder Browserunterstützung oder unzureichender Update-Frequenz ausgeschlossen. Die Analyse berücksichtigt die Wartbarkeit der Frameworks, die in dieser Arbeit durch die Subcharakteristika Analysierbarkeit, Modifizierbarkeit, Modularität, Wiederverwendbarkeit und Testbarkeit definiert wird. Die Anzahl der Codezeilen, wie von Heitkötter et al. (2012) vorgeschlagen, wird als Metrik nicht verwendet.

Die drei ausgewählten Frameworks werden anhand der Soll-Kriterien detailliert evaluiert. Dabei wird Ionic als WebView-basiertes Framework, welches Hybrid-Apps für Web, iOS und Android ermöglicht, hervorgehoben. Es nutzt Angular2 und TypeScript und bietet eine einfache Entwicklungsumgebung mit der Ionic CLI, inklusive Live-Reload. NativeScript verwendet eine Untermenge von CSS und XML-Markup zur Erstellung nativer Benutzeroberflächen und bietet hohe Performance. Jedoch erfordert der Zugriff auf native APIs und Bibliotheken detailliertes Plattformwissen. React Native, ein Runtime-basiertes Framework, basiert auf React und verwendet ES6 und JSX. Ähnlich wie NativeScript nutzt es XML-basierte Syntax und eine Untermenge von CSS für die Benutzeroberfläche. Die Dokumentation und Community-Unterstützung werden bewertet. Die jeweiligen Vor- und Nachteile bezüglich einfacher Entwicklung, der Wiederverwendung von Code und der Anpassung an unterschiedliche Plattformen werden diskutiert.

Die Arbeit vergleicht die Frameworks im Hinblick auf ihre Unterstützung verschiedener Plattformen und die damit verbundene Wiederverwendung von Code. Zwei Konzepte werden unterschieden: die vollständige Wiederverwendung des Benutzerinterface-Codes und separate Implementierungen für Web und mobile Plattformen. Aus Wartbarkeitsperspektive wird die Wiederverwendung des Benutzerinterface-Codes für alle Plattformen favorisiert. Der Umgang mit plattformspezifischen Funktionen wird analysiert. Ionic bietet durch die Ausführung in einem WebView eine plattformunabhängige Umgebung. NativeScript und React Native ermöglichen zwar eine höhere Anpassung an die jeweilige Plattform durch den Zugriff auf native APIs, führen jedoch zu plattformspezifischem Code und erhöhtem Wartungsaufwand. Ionic ermöglicht uneingeschränkte Verwendung von Dritt-Bibliotheken, im Gegensatz zu NativeScript und React Native. Der geringere Lernaufwand bei Ionic durch die Verwendung von HTML, CSS und TypeScript wird betont. Die Modularität und Wiederverwendbarkeit der Frameworks, sowie deren Architekturmuster (MVC bei NativeScript und Ionic) werden im Kontext der Wartbarkeit analysiert.

Basierend auf der Evaluation werden Ionic und NativeScript als die geeigneteren Frameworks für die Entwicklung von mobilen und Webanwendungen mit gemeinsamer Codebasis identifiziert, da beide auf Angular2 und TypeScript aufbauen. Die Verwendung von Components in React Native, welche Anwendungs- und Darstellungslogik vermischen, wird als nachteilig für die Wartbarkeit bewertet, da dies dem Prinzip 'Separation of Concerns' widerspricht. Letztendlich wird Ionic aufgrund der besseren Wiederverwendung des Quellcodes und des geringeren Entwicklungsaufwands präferiert. Die Verwendung von bekannten Webtechnologien (HTML, CSS) und die optionalen Erweiterungen von TypeScript minimieren den Lernaufwand. Ionic bietet zudem Konzepte zur Strukturierung des Quellcodes, die die Modularität und Wiederverwendbarkeit positiv beeinflussen, und folgt dem MVC-Architekturmuster.

Zur Validierung der Ergebnisse der Framework-Evaluation wurde ein prototypischer Budget-Tracker mit Ionic implementiert. Die Anwendung ermöglicht das strukturierte Speichern von Einkäufen, die Zuordnung zu Kategorien (z.B. Nahrungsmittel, Kleidung) und die Darstellung der Ausgaben in aggregierter Form als Statistik. Die Wahl von Ionic erfolgte aufgrund der vorherigen Analyse, die Ionic als das am besten geeignete Framework für Wartbarkeit und Code-Wiederverwendung identifizierte. Die Implementierung des Budget-Trackers sollte die Praxistauglichkeit von Ionic und die Validierung der aufgestellten Kriterien demonstrieren. Die Funktionalität des Prototyps dient dazu, die angegebenen Muss- und Soll-Kriterien zu überprüfen. Nicht-technische Kriterien wie die Community-Unterstützung oder die Lizenzierung wurden bereits im theoretischen Teil der Arbeit ausreichend behandelt und werden daher in der prototypischen Implementierung nicht explizit validiert.

Der Budget-Tracker umfasst eine 'Einkauf hinzufügen'-Ansicht zum Erfassen von Produktname und Preis. Die Anwendung versucht, den Ort des Einkaufs über die GPS-Koordinaten des Geräts und die Google Places API zu bestimmen. Da die Google Places API nicht clientseitig verwendet werden kann, wurde ein eigener Webservice auf Basis von Node.js implementiert, der als Middleware zwischen der Anwendung und der Google Places API agiert. Dieser Webservice ruft die Google Places API mit den vom Gerät übermittelten Koordinaten ab und leitet die Antwort an die Anwendung weiter. Die Implementierung zeigt, wie mit Ionic plattformübergreifende Anwendungen erstellt und gleichzeitig auf gerätespezifische Funktionen (GPS-Sensor) zugegriffen werden kann, während gleichzeitig die Codebasis möglichst einheitlich gehalten wird. Dies verdeutlicht die Stärken von Ionic bezüglich Wartbarkeit und Code-Wiederverwendung.

Die prototypische Implementierung des Budget-Trackers diente der Validierung der im theoretischen Teil aufgestellten Kriterien. Der Fokus lag dabei auf den Muss- und Soll-Kriterien, die sich durch den Prototypen technisch verifizieren lassen. Kriterien wie die Existenz von Kommunikationskanälen in der Framework-Community oder die Lizenzierung des Frameworks wurden im vorherigen Kapitel bereits ausreichend behandelt. Die Implementierung mit Ionic, unter Verwendung von HTML, CSS und TypeScript, zeigte die einfache Entwicklung und den geringen Lernaufwand. Der TypeScript-Compiler (TSC) und die Ionic CLI unterstützten die Entwicklung durch Fehlermeldungen und automatische Neukompilierung. Der generierte JavaScript-Code verdeutlicht die Funktionsweise von TypeScript als 'Syntactic Sugar' mit statischer Typisierung nur während der Entwicklung. Die Wiederverwendbarkeit des Quellcodes für verschiedene Plattformen wurde durch die prototypische Anwendung bestätigt. Herausforderungen bezüglich der Darstellung auf Geräten mit hohen Bildschirmauflösungen und die Notwendigkeit zusätzlichen Implementierungsaufwands für Anpassungen des Layouts wurden dokumentiert.

Die Arbeit zeigt, dass die Erstellung von mobilen und Web-Anwendungen aus einer gemeinsamen Codebasis mit dem Framework Ionic erfolgreich umgesetzt werden kann. Im Vergleich zu NativeScript und React Native bietet Ionic den höchsten Grad an Quellcode-Wiederverwendung für iOS, Android und den Webbrowser. Die Verwendung eines einheitlichen Technologie-Stacks (HTML, CSS, TypeScript) minimiert den Aufwand und erhöht die Einheitlichkeit der Codebasis. Die Implementierung eines prototypischen Budget-Trackers bestätigt die Vorteile von Ionic hinsichtlich Wartbarkeit und Entwicklungsaufwand. Die einfache Integration von Dritt-Bibliotheken und die Verwendung von TypeScript mit seinen optionalen statischen Typisierungsmöglichkeiten tragen zur verbesserten Wartbarkeit bei. Das MVC-Architekturmuster, welches durch die Integration von Angular2 vorgegeben wird, bietet eine strukturierte Codebasis, was wiederum die Wartbarkeit vereinfacht.

Während Runtime-basierte Frameworks wie NativeScript und React Native durch die Trennung der Benutzeroberfläche eine höhere Anpassung an die jeweilige Plattform ermöglichen, werden sie aus der Perspektive der Wartbarkeit als weniger geeignet bewertet. Der erhöhte Aufwand durch die Notwendigkeit plattformspezifischen Codes und das fehlende einheitliche Konzept für das User Interface führen zu erhöhtem Entwicklungs- und Wartungsaufwand. Die Arbeit zeigt jedoch auf, dass weitere Forschung die Implikationen dieser Ansätze hinsichtlich Wartbarkeit untersuchen sollte. Die Nachteile in Bezug auf Wartbarkeit werden im Detail diskutiert, inklusive der Problematik der Trennung von Anwendungslogik und Darstellungslogik bei React Native und der Notwendigkeit von frameworkspezifischem Wissen bei NativeScript.

Die Arbeit betont die Relevanz einer detaillierten Analyse der Wartbarkeit von JavaScript, insbesondere angesichts seiner Unzulänglichkeiten in diesem Bereich. Der Entscheidungsprozess für die Auswahl geeigneter Technologien muss jedoch immer mehrere Perspektiven berücksichtigen, nicht nur die Wartbarkeit. Faktoren wie Benutzerfreundlichkeit und Anwendungsperformance spielen ebenfalls eine entscheidende Rolle. Die Arbeit regt an, die Implikationen des Konzepts separater Benutzerinterfaces für unterschiedliche Plattformen (wie in NativeScript und React Native) im Hinblick auf die Wartbarkeit in zukünftigen Arbeiten genauer zu untersuchen. Mit der zunehmenden Verbreitung von ECMAScript 2015 und TypeScript dürfte die Relevanz der Wartbarkeitsperspektive im Vergleich zu anderen Aspekten, wie Benutzerfreundlichkeit und Performance, in Zukunft abnehmen.