Qualität ist ein entscheidender Aspekt der Softwareentwicklung. Um sie zu erreichen, bedarf es mehr als nur guter Vorsätze. In der Realität des Projektgeschäfts erhöhen begrenzte Ressourcen an Zeit und Budget den Druck. Dieser Blogartikel beschreibt einen Weg zu nachhaltiger und qualitativer Softwareentwicklung unter realen Bedingungen.
Entwicklung unter Druck
Produktentwicklung geschieht meist mit einer langen Laufzeit im Blick. Investitionen in hohe Codequalität zahlen sich in einem solchen Umfeld unter Garantie aus: Verständlichkeit und saubere Strukturen stellen sicher, dass der Code von einem größeren Team oder nachfolgendem Personal im Projekt gewartet und weiterentwickelt werden kann.
Anders sieht es oft im Bereich des Projektgeschäfts aus: Das Budget ist eng, dementsprechend auch die Zeitschiene und die Entwicklungs-Ressourcen, die für das Projekt eingesetzt werden können.
Teilmigration in bestehender Lösung
Ein solcher Fall ist die vorletztes Jahr erfolgte Migration des Web Frontends der SaaS-Lösung Fast@Home. Sie wird von Esri Deutschland zusammen mit atesio entwickelt, betrieben und gewartet. Die Lösung existiert schon seit fast einem Jahrzehnt und ist am Markt etabliert. Fast@Home ermöglicht die webbasierte Planung kostenoptimierter Glasfaseranschlussnetze.
Fast@Home setzt bei der Glasfasernetzplanung auf modernste, mathematische Optimierungsmethoden von atesio. Die Algorithmen optimieren den Trassenverlauf, um die Tiefbaukosten signifikant zu reduzieren.
Das Web-Frontend von Fast@Home wurde initial mit dem WYSIWYG-Editor “Web AppBuilder for ArcGIS” entwickelt und beinhaltet eine Reihe ausgefuchster Custom Widgets und natürlich eine übersichtliche, interaktive Karte zur Visualisierung der Ergebnisse. Dieser Editor wurde mittlerweile zusammen mit der Generation 3.x. des ArcGIS Maps SDK for JavaScript abgekündigt und Mitte 2024 in den Ruhestand geschickt. Dementsprechend war eine Migration der Frontend-Komponente unumgänglich.
Die Konditionen
Neben begrenztem Budget und engem Zeithorizont war eine wichtige Leitlinie in diesem Migrationsprojekt, die Bestandskunden genauso komfortabel wie vorher im Client bei ihrer täglichen Arbeit zu unterstützen.
Der etablierte Arbeitsablauf – vom Upload über das Editieren der Daten, das Setzen von Berechnungsparametern, die Validierung der Daten bis hin zum Anstoß der Datenverarbeitung – sollte nicht gebrochen werden. Die funktionalen Änderungen betrafen oft geäußerte Kundenwünsche, die bislang nicht umgesetzt werden konnten. Ansonsten wurden die Custom Widgets konzeptionell 1:1 übertragen. Das neue User Interface (UI) verwendet natürlich schicke UI-Elemente aus dem Jimu Framework und dem Calcite Design System und kommt moderner daher als der Vorgänger.
Technische Schritte
Eine zentrale Frage war, wo bestehender Code übernommen werden kann und wo Neuentwicklung erforderlich sein würde. Ein völlig klarer Fall von Neuentwicklung waren die Widgets, denn die Frontend-Komponenten des Web AppBuilder (WAB) sind nicht mit denen des Experience Builder (ExB) kompatibel.
Der Business-Code jedoch, der ursprünglich als Vanilla-JavaScript unter Verwendung der 3.x ArcGIS API for JavaScript geschrieben wurde, sollte funktional unverändert übernommen werden. Dabei wurden die folgenden Schritte unternommen:
- Migration nach TypeScript: Die alten Business-Code-Klassen wurden in TypeScript überführt, was zukünftige Fehler vermeidet und den Entwicklungskomfort erhöht, beispielsweise durch Typsicherheit, Intellisense und ES6-Features. Gleichzeitig ist Codemigration immer eine potenzielle Fehlerquelle.
- Umstellung auf aktuelle Technologien: Die Verwendung des ArcGIS Maps SDK for JavaScript 4.x sowie funktionaler React-Komponenten führte zu einer deutlichen Verbesserung der Wartbarkeit, Lesbarkeit und Erweiterbarkeit des Codes. Vermischungen von Business- und UI-Logik, wie im alten Client noch vorhanden, wurden konsequent ausgeräumt.
- Refactoring zur Testbarkeit: Ein großer Fokus lag darauf, Funktionen testbar zu machen. Dazu wurden gewachsene „Monster-Methoden“ in fokussierte Funktionen zerlegt, die vergleichbare Ergebnis-Objekte zurückgeben, anstatt Flags auf Klassen-Ebene zu setzen.
Testen als Kernstrategie
Angesichts der begrenzten Ressourcen wurde eine pragmatische Teststrategie entwickelt: Das Ziel war nicht, eine hohe Codeabdeckung zu erreichen, sondern eine fehlerfreie Migration sicherzustellen.
Der Business-Code des alten Clients war zu großen Teilen in separaten Business-Klassen gekapselt, allerdings formuliert in “Vanilla JavaScript”. Wir umschlossen alle neuen Funktionen von vornherein mit Unit Tests, die die Ergebnisse der neuen Routinen mit Ausgabedaten der alten Version vergleichen: Statische Eingabedaten werden in eine Funktion geschickt und mit statischen Ergebnisdaten verglichen. Gibt die Funktion den erwarteten Wert zurück, ist der Test bestanden. Schleicht sich ein Fehler im Code ein, schlägt auch der Test fehl. Wie jede moderne IDE bietet Visual Studio Code übersichtliche Zusammenfassungen aller bestehenden Tests, und anhand einer farblichen Markierung können fehlschlagende Tests leicht identifiziert werden.
Die Product Owner stellten Testdaten bereit, die realistische Projektkonstellationen abbilden und auch klar definierte Fehlerfälle enthielten. Eine lokale Version des alten Clients wurde um ein paar Zeilen ergänzt, um die Ausgabedaten zu serialisieren. Diese leichten Ergänzungen stellten ein handhabbares Risiko dar, zumal die manuelle Erstellung aller Vergleichsdaten das Budget überschritten hätte.
Diese Strategie erwies sich als erfolgreich: Durch Übertragung oder Refactoring entstehende Fehler konnten frühzeitig erkannt und behoben werden. Zudem helfen die Tests bei zukünftiger Wartung: Lösen Änderungen im Code eine Änderung des Ergebnisses aus, weist die Übersicht der Unit Tests direkt auf die problematische Funktion hin. Sollen zukünftig neue funktionale Anforderungen umgesetzt werden, die sich auf die Rückgabewerte auswirken, werden zunächst die statischen Daten angepasst und der Test damit zunächst ungültig. Ist die Implementierung im Code dann vollständig, springt der Unit Test wieder auf grün und zeigt die Erfüllung der neuen Anforderungen an.
Fazit
Die Migration des Fast@Home Frontends war ein Balanceakt zwischen Zeitdruck, begrenztem Budget und hohen Qualitätsansprüchen. Die getroffenen Entscheidungen – insbesondere die Fokussierung auf testbaren Business-Code und eine pragmatische Teststrategie – haben sich ausgezahlt und könnten als Blaupause für ähnliche Projekte dienen.
Für Bestandskunden wurde sichergestellt, dass gewohnte Arbeitsabläufe erhalten blieben. Gleichzeitig profitieren Anwender von Performance-Verbesserungen und einer moderneren, logischeren Oberfläche. Auf der Entwicklungsseite wurde die Codequalität erheblich verbessert. Zusammen mit der Nutzung von React und TypeScript macht das die künftige Pflege effizient und zukunftssicher.
