Backend, Frontend, Happy End? Tocco-Entwickler über die Arbeit zu Release 3.0

Wie kam es dazu, dass das Backend neu gemacht wurde?

Michi
Angefangen hat alles mit meinem Impuls, das bestehende Framework durch Spring Boot zu ersetzen.

Luca
Ja, der Backend-Teil war wirklich nicht mehr sehr fresh.

Michi
Nicht sehr fresh ist gut. Die Arbeit damit ist zeit- um nicht zu sagen nervenaufreiben. Alles muss in XML konfiguriert werden. Der Einsatz aktueller Technologien ist gerade unter Entwicklern ein grosses Plus in der Rekrutierung.

Luca
Definitiv, verbreitete Standards öffnen uns und machen uns bei Entwickler-Talenten interessant. Aber das gesamte Framework neu aufzusetzen, war sowieso an der Zeit. Grosse Code-Blöcke wurden noch von Mitarbeitenden erstellt, die nicht mehr hier arbeiten. Und die alte Technik erschwert die Nachvollziehbarkeit. Die neue Standardisierung hilft hier sehr.

Stefan
Vergleichen wir die Software mit einem Haus, haben wir nur die Wände stehen gelassen und sonst alles rausgerissen, abgerissen und neu gebaut.

Michi
Wie man es nimmt – man könnte auch sagen, wir haben die zugrunde liegende Technologie ausgetauscht. Die ganze Logik und der grösste Teil des Codes wurden nicht angepasst.

 

 

Wie ging es mit diesen Erkenntnissen zur alten und neuen Technik weiter?

Michi
Das Thema lag schon länger auf dem Tisch.

Stefan
Nicht zuletzt dank der neuen Leitung wurde das Thema bei der Geschäftsleitung priorisiert.

Adrian
Ja, wir haben bei Marcel insistiert und übers Backlog gesprochen und er hat den entscheidenden Schritt gemacht, indem er uns die Ressourcen organisiert hat.

Michi
Ein weiterer Grund, weshalb wir nicht früher eingegriffen haben, ist der schiere Umfang dieser Arbeit, die man nicht blockweise umsetzen kann. Man muss das gesamte Backend auf einmal neu aufsetzen. Hier besteht ein gewisses Risiko die Funktion zu beeinträchtigen. Auch der Aufwand muss gut geschätzt werden, um die zu leistende Arbeit passend in den Alltagsprozess integrieren zu können. Ein Trick war schlussendlich, zwei Versionen zusammenzuführen. So hatten wir statt der üblichen drei Monate Entwicklungszeit für eine Version sechs Monate Zeit.

Stefan
Drei Monate wäre schon sehr anspruchsvoll, vor allem mit den Arbeiten rund ums Fixing.

Luca
Zugewartet mit dem Umbau hat man auch ganz einfach, weil die bestehende Lösung sehr gut funktioniert hat.

Michi
Stimmt schon – wir hatten kaum Probleme mit HiveMind. Die Arbeit damit war einfach umständlich.

Luca
Jetzt lässt sich viel besser nachvollziehen, was passiert und die Entwicklungsumgebung versteht es auch. Und – es ist üblicher Java-Code.

Stefan
Genau. Das Framework ist dokumentiert, so kann man alle Funktionen nachlesen und man muss nicht selbst per Test herausfinden, was passiert.

 

Man minimiert also auch die Abhängigkeit von Personen, die das Wissen haben?

Michi
Ja genau. Und neue Entwickler kennen das Framework schon, im Gegensatz zu HiveMind.

 

Wie war denn der konkrete Ablauf, des Neubaus des Backend?

Stefan
Zuerst haben wir einen Prototyp gebaut – zu Evaluationszwecken mit zwei Frameworks, Spring Boot und Quarkus. Mit diesen Prototypen haben wir die wichtigsten Features ausprobiert um die Machbarkeit zu prüfen.

 

Warum hat man sich also für Spring Boot entschieden?

Michi
Wir haben konstant alle Funktionen in beiden Frameworks getestet. Schnell stellte sich heraus, dass mit Spring Boot alles einfacher ist. Quarkus ist halt auch neuer, es sind weniger Beispiele und Erfahrungen vorhanden. Es scheint mir auch eher für Microservices optimiert.

Luca
Spring Boot ist einfach das etablierte Framework für die Java-Umgebung.

 

Nach dem Entscheid für Spring Boot, wie wurde das Projekt vorangetrieben?

Adrian
Direkt über Marcel. Er hat den Stand mit der Geschäftsleitung diskutiert und die Weiterführung des Projektes beantragt. Die Rückfrage war absehbar – wie lange dauert das und was kostet es uns?

Michi
Was ich auch verstehe, schliesslich kann man den Kunden nichts direkt verkaufen mit diesem Aufwand.

Adrian
Hört sich jetzt komisch an, aber die Idee ist, dass sich für Kunden gar nichts ändert oder besser gesagt, die Kunden sollen vom Wechsel gar nichts merken. Im Hintergrund aber läuft eine Technik die sicherer ist und die in Zukunft einfacherer erweiterbar ist.

Stefan
Ja, idealerweise merkt der Kunde nichts davon, hat er doch nur mit dem Frontend Kontakt.

Michi
Was schon einfach ist und das ist interessant für den Kunden, dass wir einfacher neue Features machen können. So bestehen schon diverse Plug-ins, für Spring Boot, die wir nun verwenden können, statt die Funktionalität selber nachzubauen.

 

Somit werden für euch wieder Kapazitäten frei?

Luca
Ja, besonders bei Custom-Erweiterungen. Das war mit HiveMind sehr aufwändig und eingeschränkt war man auch. Jetzt können wir einfach frei drauflos Java-Code schreiben und wir brauchen keine Rücksicht mehr auf die Einschränkungen des HiveMind-Frameworks hinnehmen. Wie sehr uns der Wechsel das Leben tatsächlich leichter macht, sehen wir aber erst in den kommenden zwei, drei Releases, sobald wir mit den Kundenmigrationen beginnen.

Adrian
Bei selbstgemachten Funktionen wie unserer Login-Logik mit Single-Sign-on und Zweifaktor-Integration gibt es von Spring Boot zum Beispiel vorgefertigte Lösungen wo man einfach Optionen zuschalten kann.

Michi
Ja, Spring Security könnte nun hier verwendet werden.

Adrian
Genau. Hier wird es eher zu Entscheidungen führen, ob wir bestehende Lösungen nutzen oder weiterhin selbst entwickeln. Es könnte auch sein, dass man diese Eigenentwicklungen der Community anbietet.

Luca
Ja, das ist selten der Fall.

Adrian
Im neuen Frontend sind Open Source-Komponenten im Einsatz.

Ein grosser Brocken – wie wurde das hinsichtlich Ressourcen und Planung umgesetzt?

Adrian
Der wichtigste Entscheid war, die Produktentwicklung der 2.x-Releases zurückzufahren. Auch Juan, unser Product Owner, hat während dieser Zeit seinen Fokus auf den neuen Client gelegt.

Michi
Und ein gewisses Mass an Reserve war schon vorhanden.

Adrian
Ausserdem werden die meisten Kunden-Aufgaben vom Business Services 2nd erledigt.

 

Wie habt ihr im Team zusammengearbeitet? Meetings? Tools?

Luca
Michi hat vorab alles vorbereitet, vor allem die komplexen Themen. Der Grossteil der Arbeit war, die einzelnen Module zu migrieren. So waren die einzelnen Arbeitsschritte relativ unabhängig voneinander. Ab und zu gab es ein Feature, das gemeinsam besprochen werden musste.

Adrian
Erschwert wurde diese Arbeit durch die Abhängigkeit der einzelnen Module untereinander.

Michi
Die meisten Use-Cases wurde ja vorab getestet. Danach folgte ein grosser Teil Fleissarbeit. 90 % der Fälle war klar, wie zu migrieren.

Adrian
Für die Listener mussten wir einen Trick anwenden, wie sie anzuschreiben sind und wo sie greifen. Michi du hast doch diesen Trick gemacht?

Michi
Welcher Trick?

Adrian
Der mit der Listener-Annotation, die eine Map generiert inklusive Filter. Zusätzlich findet man natürlich im Internet Ressourcen, die in solchen Fällen zur Anwendung kommen.

 

Also der Schlüsselmoment war die Evaluation der neuen Technologie und Prüfung mit der bestehenden Tocco-Technologie?

Luca
Ja.

 

Wie lange dauerte der Evaluationsprozess?

Adrian
So über den Daumen gepeilt so 10 bis 15 Tage. Zuerst haben wir zusammen evaluiert, was macht unser altes Framework, wie konfigurieren wir dort was. Dann ging es darum herauszufinden, wie können wir im neuen mache, was wir im Alten machen. Danach wurde der Prototyp erstellt. Das alles funktionierte schon von Beginn an sehr gut. Die grösste Hürde ist, dass alles neu gemacht werden musste – die Fleissarbeit schlussendlich.

Michi
Geholfen hat aber schon auch die Vorbereitung der Module in der Version 2.29.

Adrian
Die Modulabhängigkeiten untereinander führten zu Komplikationen, die konnte in den Modulkonfigurationen herausgelesen werden. Diese Konflikte mussten gelöst werden per Release 2.29.

(Anmerkung: Der effektive Aufwand für die Realisation belief sich auf über 800 Stunden.)

 

Und wie führte dies zum neuen Client?

Michi
Der Client ist seit fünf Jahren in Arbeit. Motivation ist auch hier die in die Jahre gekommene Technologie.

Luca
Ext 3 oder 4 ist im Einsatz, aktuell ist 7.

Michi
Ja aber auch das sehe ich nie im Einsatz bei den coolen Projekten. Alte Technologie also, mühsam zum Arbeiten damit. Und es gibt mehr Entwickler, die React kennen.

 

Gilt es nicht, das Auflaufen auf alte Technologien zu vermeiden?

Adrian
Das ist noch schwierig. Für einen Technologiewechsel muss ja alles in der neuen Technologie gebaut werden.

Stefan
Wenn man nie das Update durchführt, wird es irgendwann überproportional kompliziert, das Update durchzuführen.

Adrian
Bei Ext ist es auch so, dass sich von 3 auf 4 sehr viel geändert hat und es war nicht einfach so aktualisierbar.

Stefan
Dann hat man noch das Gefühl im alten Frontend ist viel mehr ausprogrammiert und im Neuen versucht man, es generischer zu lösen. Abstraktion machts einfacher.

Luca
Im Frontend-Bereich hat sich auch über die letzten zehn Jahre sehr viel verändert, von den Paradigmen her. Und das unterliegende JavaScript hat sich stark weiterentwickelt. Viele Sachen im Ext können wir schlichtweg nicht brauchen, die es neu gäbe, weil das Ext die Language-Features nicht unterstützt. Man müsste also alles bei jeder Version vom Neukunden upgraden. Also den alten Client auf die neue Ext-Version portieren wäre mehr Aufwand, als einfach einen neuen zu schreiben.

Michi
Definitiv ein Unterschied ist, dass der User merkt, dass das Frontend neu ist.

Adrian
Der Backend-Austausch fand in einem halben Jahr statt, das Frontend dauerte rund fünf Jahre. Im Frontend haben wir zuerst geprüft, welche Komponenten verfügbar sind und welche wir brauchen können. Vom Kleinen kamen wir ins Grosse.

Luca
Die Tabelle hatten wir als erstes Element fertig im Frontend.

Stefan
Das ist sicher auch ein entscheidender Unterschied von Frontend und Backend. Im Backend findet der Wechsel in einem Schritt statt, im Frontend kann Schritt für Schritt gewechselt werden. Darum gibt es auch die Legacy-Actions im neuen Client.

Besten Dank für das Gespräch und dem Café des Amis für die Gastfreundschaft.