Nötig und nützlich

Migration von AngularJS zu Angular

Zürich, Apr 2019

Nachdem Google ankündigte, die Unterstützung von AngularJS einzustellen, entschieden wir uns im Sommer 2017 unser Produkt reclaimer® von AngularJS auf Angular zu migrieren. Es war eine bedeutende Aufgabe: Wir hatten eine ziemlich grosse Anwendung, ein neues Framework und die zusätzliche Komplexität eines hybriden Ansatzes.

Diese "Investition" würde jedoch zu einem stabileren und effizienteren Produkt führen, welches auf moderner Technologie basiert. Die Webentwicklung und insbesondere der Javascript-Bereich entwickeln sich in einem erstaunlichen Tempo. Da kann es schwierig sein Schritt zu halten, insbesondere wenn man wie in diesem Fall ein 8-jähriges Framework verwendet, welches immer weniger von der Community unterstützt wird. Die Umstellung von AngularJS auf Angular hat es uns ermöglicht, moderne Entwicklungswerkzeuge und -techniken einzusetzen. Es hat uns Zugang zu einer grösseren Bandbreite an Community-Tools und Bibliotheken verschafft, die sich enorm positiv auf unser Produkt ausgewirkt haben. Die Digitalisierung führt zu einer grösseren "Kundenliquidität", was bedeutet, dass Kunden leichter zwischen Produkten und Plattformen wechseln können. Deshalb ist es von grösster Bedeutung, mit der Entwicklung mitzuhalten.

Warum sollte man Ressourcen an die Migration von AngularJS zu Angular «verschwenden»?

Ältere Produkte, Systeme und Anwendungen, die zwar gut laufen aber veraltete Technologien verwenden, sind von Natur aus Träge. Zeit und Ressourcen in die kurzfristige Aktualisierung eines erfolgreichen Produkts zu investieren, scheint Verschwendung. Doch der eigentliche Grund warum die Migration nötig ist, ist dass AngularJS bald veraltet sein wird (es befindet sich derzeit in der "Langzeitunterstützung" bis Juni 2021, danach wird es keine Unterstützung mehr geben). Damit ist es nur eine Frage der Zeit, bis AngularJS-Anwendungen nicht mehr wartungsfähig sind. Diese Ankündigung war der Hauptgrund für unsere eigene Migration.

Zudem läuft Support von anderen Entwicklern im Sinne von Bibliotheken und anderen Tools aus. Während unserer eigenen Migration stellten wir fest, dass die von uns verwendeten Tabellen bereits veraltet waren; wir konnten sie nicht migrieren und mussten sie komplett neu schreiben. Insgesamt untermauert dies die Feststellung, dass AngularJS eine veraltete Technologie in einem schnelllebigen Umfeld ist und einfach nicht mithalten kann. Die Entwicklungseffizienz und die Anwendungsqualität werden durch diese Umstellung verbessert, wobei die in AngularJS geschriebenen Anwendungen bereits veraltet und sperrig daherkommen. AngularJS ist nicht nur überholt, der Nachfolger Angular bietet auch eine Menge neuer nützlicher Funktionen. Die Verwendung von Typescript, AngularCLI und vorzeitiger Kompilierung, sowie viele andere Features, können zu grossen Effizienzsteigerungen führen.

Weiterhin gilt: Je länger man wartet, desto grösser wird die Aufgabe letztendlich sein. Wenn man jetzt mehr Funktionen und Komplexität zu Ihrer Applikation in AngularJS hinzufügen, wird dies Ihrem späteren Migrationsauftrag Zeit und Kosten bescheren. Mit einem Endtermin für AngularJS ist die Weiterentwicklung mit diesem Rahmen verschwenderisch und kontraproduktiv. Wenn Sie Ihrer Anwendung neue Funktionen und Updates hinzufügen möchten, kann dies während oder im Zusammenhang mit dem Migrationsprozess erfolgen. Angesichts des nahen Endes von AngularJS ist es sinnvoller Ressourcen in die Migration zu stecken, anstatt in die kurzfristige Aktualisierung der AngularJS-Anwendung. Die Kapitalrendite leitet unter jeder weiteren AngularJS-Entwicklung.

Zu guter Letzt, wenn andere zu Angular wechseln, können Ihre AngularJS-Anwendungen inkompatibel werden. Beispielsweise müssen diejenigen auf der Avaloq-Frontplattform (AFP) ihre Anpassungen migrieren, um bei Übergängen mit dem AFP kompatibel zu bleiben. Dieser Umstand kann früher als der letzte Tag von AngularJS kommen.

Migrationsmethoden

Abhängig von Ihrer Anwendung stehen drei Hauptmethoden der Migration zur Verfügung.

Von Grund auf neu anfangen

Die offensichtlichste Methode ist, einfach bei null anzufangen. Wenn Ihre Anwendung knifflig oder aufwendig ist, mit umständlichem Code, der am besten neu geschrieben werden sollte, kann es ratsam sein, neu zu beginnen. Darüber hinaus können bei komplexen Anwendungen die Lernkurve und die fehlende Dokumentation im Zusammenhang mit der Hybrid-Methode (siehe unten) Probleme und langsame Fortschritte verursachen. Ein Neuanfang kann zu einem reibungsloseren Arbeitsablauf und weniger Fehlern führen. Verfügen Sie über genügend Ressourcen, können Sie sowohl die alte Anwendung pflegen als auch eine neue Anwendung von Grund auf neu entwickeln, und zwar gemeinsam mit zwei Teams, was sinnvoll sein kann. Allerdings wäre es in der Regel recht ineffizient. Ab AngularJS 1.5 kann der Code in einem ähnlichen Stil wie Angular geschrieben werden - die Klassen von AngularJS sind mit den Komponenten in Angular vergleichbar - was bedeutet, dass eine Hybridmigration einen erheblichen Teil wiederverwenden würde. Wenn Sie derzeit nicht über genügend Ressourcen verfügen, um zwei Teams zu leiten, werden neue Entwickler, die mit der Anwendung nicht vertraut sind, den Prozess weiter verlangsamen.

Hybridverfahren

Bei diesem Verfahren werden sowohl AngularJS als auch Angular nebeneinander verwendet. Mit ngUpgrade können Sie beide Frameworks parallel laufen lassen und die Komponenten für die Kompatibilität verschachteln. Dies ermöglicht Ihnen Teilmigrationen, welche direkt mit den regulären Releases Ihrer Applikation ausgeliefert werden können. Wenn Sie AngularJS 1.5+ mit Klassen verwenden, wird dies den Übergang aufgrund seiner Ähnlichkeit mit Angular noch einfacher machen. Die Hybrid-Methode erfordert weitaus weniger Ressourcen als ein Neuanfang, da dasselbe Team sowohl die Wartung als auch die Migration übernimmt. Wahrscheinlich wird es die Entwicklung günstiger machen. Es verhindert auch das Problem unerfahrener Entwickler während der Teamentwicklung, das manchmal durch die "von Grund auf neu" Methode bedingt ist. Allerdings ist auch dieser Ansatz nicht ganz ohne Probleme. Es besteht ein gravierender Mangel an Dokumentation bezüglich der Migration einer komplexen Anwendung von AngularJS nach Angular. Darüber hinaus konzentriert sich diese vor allem auf die neuesten Versionen und Schreibweisen von AngularJS. Diejenigen, die Funktionen verwenden anstatt mit Klassen Konstrukte arbeiten, werden wahrscheinlich auf viele Probleme stossen, da die komplette Dokumentation und ihre Beispiele auf der neusten Version basieren. Dies führt zu einem Try-and-Error Ansatz, bei dem Probleme mit kreativen Methoden behoben werden. Obwohl das funktioniert, kann es frustrierend sein. Ausserdem bedingt die Verschachteln-Funktionalität von ngUpgrade eine steile Lernkurve, mit der einige Entwickler Probleme haben könnten. Dies kann zu stagnierenden Arbeitsabläufen und Frustration führen.

Nichts tun

Unsere eigene Erfahrung

Mit dem bevorstehenden Ableben von AngularJS erkannten wir die Chance, unser Produkt reclaimer® besser und zukunftsfähig zu machen. Unsere Entwickler wollten mit modernen Tools und modernen Bibliotheken arbeiten, die mit AngularJS einfach nicht möglich sind. Wir merkten bereits, dass die Unterstützung der Community abnimmt; dies wurde durch Googles Schritt, die Unterstützung bis 2021 einzustellen, noch verstärkt. Deshalb haben wir beschlossen, dass es an der Zeit ist, sich von AngularJS zu lösen.

Nach reiflicher Überlegung haben wir uns für den Hybrid-Ansatz entschieden, der den effektivsten Weg zur Lösung unseres Problems darstellt, insbesondere angesichts der verfügbaren Ressourcen. Der reclaimer® ist eine mittelgrosse Bankenanwendung mit entsprechender Komplexität. Dies machte es daher zu einem ziemlichen grossen Unterfangen.

Wir begannen im August 2017 mit der Arbeit und bauten zunächst einen kleinen Prototyp, um die Migration und Angular in den Griff zu bekommen, welche zwar ähnlich ist, aber immer noch erhebliche Unterschiede zu AngularJS aufweist. Obwohl nützlich, stellten wir bald fest, dass der Prototyp wenig Ähnlichkeit mit dem Problem hatte, vor dem wir standen. Die Komplexität unserer App führte dazu, dass die Schwierigkeit der Migration exponentiell zugenommen hatte. In unbekannten Gewässern traten wir in eine Phase des Trial-and-Error. Wir haben gelernt, wie die Migration im weiteren Verlauf funktionieren wird. Wir machten Erfahrung in der Fehlerbehebungen und mit verschiedenen Lösungsansätzen. Dies war die schwierigste Phase. Vor allem der Mangel an Dokumentation hat vieles erschwert. Die verfügbaren Ressourcen, wie beispielsweise Googles Leitfaden zur Migration, basierten auf sehr einfachen Anwendungen, die in der neuesten Version von AngularJS geschrieben wurden. Da unsere Anwendung auf Funktionen und nicht auf Klassen basierte, gab es ein gewisses Mass an Diskrepanz in Stil und Architektur, was zu Problemen und Fehlern führte. So haben wir beispielsweise die neue Anwendung ursprünglich so konzipiert, dass initial Angular geladen wird und an diesen Startknoten die einzelnen AngularJS und Angular Komponenten angehängt werden. Dies führte zu erheblichen Performance-Problemen. Wir haben keine Dokumentation gefunden, die dieses Problem erklärt. Schliesslich haben wir AngularJS vor den Angular Startknoten gehängt (Abb. 2). Damit wurde das Performance-Problem gelöst. Ebenso standen wir vor einem Problem beim asynchronen Laden von Seiten. Einige Seiten hatten Komponenten, die nach dem Rendern der Startseite geladen wurden. Obwohl die Anfrage gestellt wurde, wurde dies nicht mehr gerendert. Am Ende haben wir eine Lösung gefunden, aber auch hier fanden wir keine Erklärung online. Eine der technisch anspruchsvollsten Aufgaben bei dieser Migration war die Verpackung von Komponenten. Am Anfang hat dies das Projekt noch komplexer gemacht, da sich dadurch viele unerklärlichen Fehler eingeschlichen haben.

Durch die Migration der App wurden auch einige Funktionen komplett neu geschrieben. Tabellen, die für das ursprüngliche Produkt von zentraler Bedeutung waren, waren nun veraltet. Dies hinderte uns daran, sie einfach zu migrieren, was uns zwang, diese neuen Komponenten von Grund auf neu in Angular zu schreiben. Wir waren auch gezwungen, unsere Testinfrastruktur neu zu schreiben. Da es auf der alten App-Architektur basierte, würde es mit der neuen Struktur nicht funktionieren.

Wir haben diese Gelegenheit auch genutzt, um unser Produkt zu verbessern. Das Styling von reclaimer® hatte sich im Vergleich zu anderen Anwendungen und Plattformen im E-Banking-Bereich als veraltet erwiesen. Deshalb haben wir das Styling aktualisiert. Darüber hinaus haben wir mehr Funktionalität hinzugefügt, wie z.B. eine intelligente Suchfunktion. Insgesamt sind wir der Meinung, dass dies zu einer verbesserten Benutzerfreundlichkeit geführt hat.

Die Mitglieder des Teams welche die App testeten, Fehler suchten und behoben, haben nun ein tiefes und umfassendes Verständnis des Migrationsprozesses entwickelt. Im Januar 2018 konnten wir die Migration an unsere Kunden liefern. Obwohl sich herausstellte, dass wir nicht alle Fehler entdeckt hatten, konnten wir aufgrund der in den letzten 5 Monaten entwickelten Fähigkeiten schnell Hotfixes liefern. Die Migration ist ein kontinuierlicher Prozess, der immer noch mit regelmässigen Updates stattfindet. Wir streben an, bis zum Termin 2021 vollständig migriert zu haben.

Schlussfolgerung

Insgesamt sehen wir eine Migration von AngularJS nach Angular als notwendig und nützlich an. Es kann zur Modernisierung und Verbesserung Ihrer Anwendung beitragen, was zu einer höheren Benutzerzufriedenheit führt. Es handelt sich um einen komplexen Prozess, vor dem einige vielleicht zurückgeschreckt sind. Wenn ein Produkt an die Grenze seiner Rentabilität stösst, kann es sein, dass der Einsatz von Zeit und Ressourcen nicht ausreichend belohnt wird, um diese Zuordnung zu rechtfertigen. Wenn Sie jedoch die Vielzahl der Vorteile mit der Tatsache abwägen, dass der Google-Support bald ended, ist es jetzt an der Zeit, den Schritt zu wagen, wenn Sie mit Ihrer Anwendung eine Zukunft sehen! Unser eigener Weg war zunächst mit Fehlern behaftet. Manchmal war es ein Kampf, aber nachdem wir es mit ein paar scheinbar unwiderruflichen Fehlern zu tun hatten, gewannen wir bald die Fähigkeiten und das Selbstvertrauen, den Job zu erledigen. Wir sind völlig zufrieden damit, den Schritt gemacht zu haben, jetzt mit einem besseren Produkt und mehr Erfahrung.