Eine frage an die programmierer hier:
Ich habe eine web-app, die (aus datenschutsgruenden) an verschiedene kunden lizensiert, und vor ort auf deren server installiert wird, wo sie nur lokal zu erreichen ist. Dort passen die kunden die software individuel an, was bedeutet dass sie ihre eigenen (web-)formulare erzeugen die daten sammeln und spaeter ausgewertet werden. Die software stammt noch aus den 90ern, und das frontend sieht auch dementsprechend aus.
Das problem ist nun, dass bestimmte bestandteile modernisiert werden sollen, ohne das bei bestehenden kunden die existierenden forms kaputtgehen. Also einfach jquery rauswerfen und bootstrap rein funktioniert nicht. Selbst wenn wir die 0815-ui fuer login, suche usw. umschreiben wuerden, waere die angepasste kundensoftware kaputt die dann eben versucht auf die alte css/js dateien zuzugreifen um irgendwelche styles oder js-code anzuwenden die vor 10 jahren mal der heisse scheiss war. Die existierenden dateien muessen bleiben wo sie sind, bis der kunde sich entscheidet seine forms selbst zu erneuern.
Teil der software sind also die statischen web assets (js, css, … die in irgendwelchen ordnern auf der platte liegen), und die forms selbst sind irgendwo in der DB oder im code gespeichert.
Wie wuerdet ihr vorgehen, die app schrittweise zu erneuern, ohne die bestehenden kundenanpassungen kaputtzumachen? Mein erster instinkt waere, fuer neu hinzukommende assets versionen-verzeichnisse (z.b. js/datatables/3_0/datatables.js sowie js/datatables/latest/datatables.js ) anzulegen die dann von den forms aus verlinkt werden damit jedes form prinzipiell unabhaengig von anderen teilen ist, aber vielleicht gibt es jemanden der sowas schonmal gemacht hat und andere/bessere loesungen hat?
Neu bauen, Kunden informieren dass für die neue Version Anpassungen seiner Umgebung notwendig sind und anbieten diese Anpassungen als bezahlte Beauftragung zu machen.
Kunde kann dann entscheiden ob er auf der alten Version bleiben will, oder ob er migrieren will.
Wenn man das zu oft macht, haut dir der Kunde relativ schnell ab. Man selbst ist ja auch genervt wenn windows zum Beispiel nach Updates irgendwelche Settings vergisst
Schon wahr, aber wenn das Ding aus den 90ern stammt, sollte das schon mal drin sein.
Meiner Erfahrung nach entstehen die größten Sorgen meist dadurch, dass irgendjemand sowas irgendwann nicht gesagt hat. Alte Software zu warten über mehrere Dekaden dann auch noch kann in größeren Projekten schnell zum Millionengrab werden.
Ich würde sagen dein Vorschlag klingt erstmal vernünftig. Wir entwickeln momentan eine Webanwendung die aus verschiedenen Services/Uis besteht. Dort werden die einzelnen Services auch über ihre URL versioniert, also z.B. “example.org/api/v2/meinService”. Gibt’s da ne große Änderung, wird v3 released: Bestehende Uis können aber trotzdem noch auf v2 zugreifen - diese wird dann aber irgendwann deprecated/entfernt. Ist zwar ne andere Technologie, verhält sich aber ähnlich wie deine versionierte Ordnerstruktur.
Technisch klingt eine API-Versionierung nach einer guten Lösung.
Ganz wichtig ist dass die alte API (bzw. Assetfolder oder was auch immer) wie @Augapfel@feddit.de gesagt hat deprecated und entfernt wird. Das muss langfristig und klar kommuniziert werden.
Andernfalls wird kein Kunde den Mehraufwand investieren das neue Framework zu lernen und dann die alten funktionierenden Formulare zu migrieren.
Das ist wichtig für euch, sonst müsst ihr nun nicht nur eine Library supporten sondern effektiv zwei. Denn ohne Deprecation bleiben Altkunden beim alten und Neukunden beim neuen Framework.
Damit der Kunde sich nicht über den Tisch gezogen fühlt sollte sich die neue Version auch für ihn lohnen, z.B. mit einer schicken neuen UI und neuen Features, am besten etwas wonach Kunden schon länger gefragt haben.
Oh, und seht zu dass ihr die Doku anpasst auf die neue API, vielleicht sogar mit Migrationshilfen von der alten Version.
Darüber hat man wohl firmenintern schon diskutiert, neu schreiben ist aber (für die Entscheider) keine Option, da dann eben all die bestehenden Anpassungen der einzelnen Kunden ebenfalls hinüber wären die das System schon seit 20+ Jahren nutzen.
Wäre auch meine bevorzugte Lösung, aber das würde eine Menge anderer Leute sehr sehr unglücklich machen…
Wie oft werden denn bei dieser Software wirklich neue Features hinzugefügt? Evtl. wäre es eine Möglichkeit einfach 2 verschiedene Produkte zu haben. Die neue ohne irgendwelche Altlasten, und die alte wo man nurnoch kritische Bugs fixt.
Ja, aber nicht so wie du denkst:
Das system auf einer relativ exotischen software die ihre wurzeln irgendwo in den 70ern hat, deren existenz mir bis vor 2 monaten unbekannt war, und wofuer man auch abseits der offiziellen dokumenation praktisch 0 infos findet. Bedeutet, das der kunde auch keinen wald-und wiesen .net/java/php programmierer daran arbeiten lassen kann da syntax und programmstrukturierung ziehmlich “rustikal” sind. Die software hat auch noch unterstuetzung fuer terminalausgaben eingebaut, so richtig old-school womit man ganze tabellen schoen formatiert auf einemn 80x25er bildschirm ausgeben kann. Das wird u.a. im finanzbereich oft genutzt, wo man 200 millionen datensaetze in weniger als einer sekunde durchsuchen muss.
Am ende ist es so das kundenspezifische anpassungen gemacht werden, es werden irgendwelche neuen klassen geschrieben die im server abgelegt werden und die der kunde dann nutzen kann.
Also z.b. hat der kunde aufbau und material fuer ein gebaeude in “seiner” datenbank (selbst nach seinen eignen anforderungen angelegt) mit seinen eigenschaften gespeichert, und dann ist die anforderung eine funktion zu schreiben die daraus bestimmte werte fuer statik und festigkeit berechnet - also schon so sachen die komplexer sind und man nicht (schnell oder einfach) selbst mal eben in Excel oder SQL umsetzten kann.
Also das ist nichts triviales wo man jetzt per add-on oder so ein cookie consent banner ins wordpress blog nachladen wuerde wenn du das meinst…
Ich würde dem Kunden erstmal schildern, dass seine Software alter Dreck ist und ihm dann vorrechnen, wie viel teurer jede Wartung daran im Vergleich zu einer Neuimplementierung wäre und wann da ein Break Even zu erwarten wäre. Da Kunde nun sicher geschockt in Abwehrhaltung geht, würde ich vorschlagen, nur das nötigste an der bestehenden Software zu machen, damit er arbeitsfähig bleibt, aber zeitgleich eine neue Version in unterschiedlichen Modulen (Kunden lieben das Wort “Modul”) zu konzipieren, natürlich in der Grundversion erstmal nur mit dem nötigsten.
Wenn nur kleinere Teile modernisiert werden sollen, diese so wegkapseln, dass sie nicht mit dem alten Scheiß kollidieren. Zum Beispiel über Web Components.
Oder falls die Webapp drumherum komplett neu soll und der alte Scheiß den die Kunden noch brauchen, laufen beide separat, der alte Kram wird in den neuen inkludiert in iframes. Der iframe und die Parentseite schicken sich Nachrichten über Broadcast Channels falls sie die Form Daten voneinander brauchen.
