Wenn Sie die Ersetzung einer komplexen Webanwendung vorschlagen, sollten Sie diese zehn Aspekte nicht außer Acht lassen

Ihre Aufgabe ist es, eine komplexe Webanwendung zu analysieren und eine Ersetzung des gesamten Stacks vorzuschlagen. Wie gehen Sie dabei vor?

Dies ist der zweite Artikel in einer Reihe von Fallstudien über ein Projekt, das wir bei smartive für ein großes Unternehmen durchgeführt haben. Bevor Sie sich als Agentur entscheiden, etwas Ähnliches zu tun, sollten Sie unbedingt unseren ersten Artikel lesen, 5 Dinge, die Sie beachten sollten, bevor Sie eine komplexe Legacy-Webanwendung ersetzen.

Bei einer ausreichend komplexen Organisation ist es unmöglich, alle beweglichen Teile im Voraus zu kennen. Je mehr Sie jedoch von Anfang an über die Anwendung und ihre Umgebung wissen, desto fundierter können Sie Ihre Entscheidungen treffen und desto weniger Überraschungen werden später auftreten.

In diesem Artikel beschreibe ich unsere Analyse einer komplexen Webanwendung, einschließlich der Überlegungen, die hinter unseren Änderungsvorschlägen stehen. Vielleicht möchten Sie sich auch etwas Zeit nehmen, um diese Aspekte zu untersuchen, wenn Sie einen Vorschlag für einen Austausch ausarbeiten.

1. Funktion und Interessengruppen

Was macht die Anwendung? Wie ist der Datenfluss? Wer sind die Beteiligten? Was sind ihre Anwendungsfälle? Haben sich die Anwendungsfälle geändert? Gibt es Möglichkeiten, wie die Anwendung diese Fälle besser lösen oder ein breiteres Spektrum von Anwendungsfällen abdecken könnte?

Diese Fragen mögen einfach klingen, aber die Antworten können sehr komplex sein, und es kann viel Zeit in Anspruch nehmen, alle Funktionen der Anwendung herauszuarbeiten - und die, die sie dank Ihrer Verbesserungen erfüllen könnte. Sie müssen diesen Aspekt im Auge behalten und ihn im Verlauf Ihrer Analyse aktualisieren.

Denken Sie auch daran, dass einer der Gründe, warum Sie wissen müssen, wer die Stakeholder sind, der ist, dass Sie ihnen helfen müssen, auf den neuen Stack zu migrieren, wenn er verfügbar ist.

Unser Fall: Kurz gesagt, die Anwendung

1. Informationen über die verschiedenen Tochtergesellschaften unseres Kunden aus verschiedenen Quellen importiert,
2. die Daten über eine REST-API zugänglich gemacht und
3. stellte verschiedene konfigurierbare Web-Clients zur Verfügung, die die Niederlassungen auf einer Karte anzeigten, mit Such-, Filter- und Detailfunktionen.

Verschiedene Beteiligte innerhalb und außerhalb des Unternehmens zogen die Daten entweder direkt von der API ab oder betteten bestimmte Varianten des Clients, die für ihre spezifischen Bedürfnisse konfiguriert waren, in ihre Webseiten ein.

Die Hauptfunktion der Anwendung sollte natürlich die gleiche bleiben. Wir sahen vor allem das Potenzial für eine allgemeinere, sauberere und schnellere Schnittstelle (sowohl auf der API- als auch auf der GUI-Seite).

2. Projektstruktur, Versionierung und Versionsverwaltung

Wie viele Repositories hat das Projekt, und wie sind sie organisiert? Welche Versionierungssoftware wird verwendet? Wie werden die Projektversionen verfolgt?

Unser Fall: Die Anwendung war ein einziges SVN-Repository, das 3 Hauptordner enthielt (Importer, Logik, Web).

In unserer neuen Lösung haben wir uns für getrennte GIT-Repositories für verschiedene Hauptfunktionen (Importer, API, Client-Code) entschieden, was ein besseres paralleles Arbeiten und getrennte Entwicklungszyklen und Releases ermöglicht. Wir strukturierten die Projektversionen und -zweige nach dem GitFlow Modell.

3. Paket- und Build-Management

Welchen Paketmanager verwendet das Projekt? Wie wird die Erstellung automatisiert? Wann werden die Tests durchgeführt?

Unser Fall: Das ursprüngliche System war ein Maven Projekt.

Wir wählten NPMweil es zu unserer Kernkompetenz passt (siehe Abschnitt Servertechnologie auf der rechten Seite) und weil es ein überwältigender Erfolg als Paketregistrierung ist.

4. Integration

In welcher Umgebung wird die Anwendung eingesetzt? Wie? Wann?

Unser Fall: Der Antrag hatte dev, qual und prod Umgebungen wurde die Bereitstellung auf diesen Systemen manuell konfiguriert und eingeleitet mit Jenkins.

Wir haben eine ähnliche 3-Ebenen-Struktur beibehalten (dev, Test, prod), aber die automatische Bereitstellung mit GitLabkontinuierliche Integrationsfunktionalität, die auf dem bereits erwähnten GitFlow-Modell aufbaut.

1. Die Aktualisierung der entwickeln. Zweig löst eine Bereitstellung an dev
2. Aktualisieren einer Freigabe/... oder hotfix/... löst eine Bereitstellung an Test
3. Das Schieben eines neuen Versions-Tags löst eine Verteilung an prod

5. Server-Technologie

Welche Servertechnologie und welche Frameworks verwendet die Anwendung?

Unser Fall: Der Antrag stützte sich auf Java Frühling, laufen mit Tomcat.

Bei smartive bauen wir stark auf Node.jsWir sind der Meinung, dass wir mit einer einzigen Sprache den gesamten Stack abdecken können, weil das Ökosystem unglaublich dynamisch ist. Unsere Erfahrung ist, dass TypScript ist sehr gut für Unternehmensanwendungen geeignet und bietet gleichzeitig die Flexibilität, die eine moderne Webagentur benötigt. Zur Erstellung der API haben wir Giuseppeein intern entwickeltes, auf Anmerkungen basierendes Routing-System für Controller.

6. Client-Technologie

Welche Web-Frameworks werden für die Ausführung des Client-Codes verwendet?

Unser Fall: Die Client-Seite basierte stark auf benutzerdefinierten JQuery-Plugins, einschließlich eines obskuren Template-Systems namens jquery-tmpl.

Leider konnten wir hier nicht unsere eigene Lieblingstechnologie wählen (was derzeit entweder Angular 2 oder React wäre). Die Anforderung war, dass wir das neue Client-Widget als Teil einer kundenspezifischen, gemeinsam genutzten Komponentenbibliothek implementieren, die mit Exoskelett - immer noch eine große Verbesserung im Vergleich zum reinen Original JQuery Umsetzung.

7. Abhängigkeiten von externen Daten

Importiert das System Daten aus anderen Quellen? Mit welcher Häufigkeit? Welche Technologien werden verwendet? Wer ist für diese Schnittstellen zuständig?

Unser Fall: Das System importierte Daten aus verschiedenen Systemen (Oracle-Datenbanken, SAP, sogar Excel-, CSV- und XML-Dateien) über REST, SOAP und einen FTP-Server. Einige der Importe liefen täglich, einige stündlich.

Gemeinsam mit dem Kunden haben wir Wege gefunden, die Datenquellen zu konsolidieren und die Abhängigkeit von FTP zu minimieren. Das ist vielleicht nicht immer möglich, da die Datenquellen hauptsächlich außerhalb Ihrer Kontrolle liegen.

8. Datenmodell

Ein entscheidender Punkt. Wie sind die Daten strukturiert? Sind sie gut strukturiert / normalisiert? Wie verhält sich die Datenstruktur zu den tatsächlichen Anwendungsfällen? Wie gut ist sie für diese geeignet? Gibt es wichtige Unterschiede zwischen der Art und Weise, wie die Daten in den externen Quellsystemen strukturiert sind, wie sie in der Datenbank gespeichert sind, wie sie in der API bereitgestellt werden und wie sie von den Kunden tatsächlich verwendet werden?

Anhand des Datenmodells/der Datenmodelle erhalten Sie eine Vorstellung davon, wofür das System gebaut wurde und wie es sich im Laufe der Zeit entwickelt hat. Alles, was Sie am Datenmodell nicht verstehen, deutet wahrscheinlich auf einen Anwendungsfall hin, den Sie nicht vorhergesehen haben.

Die Möglichkeit, eine brandneue API vorzuschlagen, ist ein absoluter Luxus und sollte genutzt werden. Es gibt keinen besseren Zeitpunkt, um die Datenstruktur sorgfältig zu bereinigen, veraltete Felder zu entfernen, verschiedene "Verbositäten", eine einheitlichere Benennung usw. bereitzustellen.

Unser Fall: Der wichtigste Objekttyp war ein Laden Siehatte jeder Store eine Standort und mehrere Sortimentedie ihrerseits verschiedene Arten von Dienstleistungen.

Beispiele für Dinge, die wir durch die Migration bereinigen konnten:

• Bei näherer Betrachtung stellten wir fest, dass Sortimente eine denormalisierte Liste, die Elemente zweier verschiedener Typen enthält: tatsächliche Sortimente und etwas anderes, das wir dann Märkte. Die Kunden mussten diese gemischten Listen analysieren und herausfiltern, was sie benötigten. Außerdem wurden sie als Key-Value-Map statt als Array bereitgestellt, was zu großen Problemen mit mehreren Sortimente mit demselben Typ. Bei unserer Neugestaltung konnten wir das alles entflechten.
• Ein weiterer Aspekt waren die Öffnungszeiten: In der Bewerbung wurden sowohl Läden und Märkte unterstützte Öffnungszeiten. Bei Kundenanwendungen sahen wir, dass es einfacher wäre, nur Markt Öffnungszeiten. Als wir die Daten aus der ursprünglichen Quelle und die Art und Weise, wie sie importiert wurden, analysierten, stellten wir fest, dass die Laden Sie Die Öffnungszeiten waren ohnehin ein Artefakt des Importeurs, der einfach die Öffnungszeiten eines bestimmten Markt. Bei unserer Neugestaltung haben wir glücklicherweise auf Laden Sie Öffnungszeit.

Das ist der wichtigste Punkt: Es ist wirklich wichtig, dass verstehen. das Datenmodell und wie es zustande gekommen ist. Gehen Sie nicht davon aus, dass es am besten so strukturiert ist, wie es ist, wenn das Projekt an Sie übergeben wird, sondern fragen Sie sich, ob es (noch) sinnvoll ist. Diese Beobachtungen können erhebliche Möglichkeiten zur Entwicklung einer saubereren und einfacheren Anwendung bieten.

9. Datenspeicherung

Wie werden die Daten gespeichert und abgerufen?

Unser Fall: Die Anwendung speicherte die importierten Daten in einer MySQL-Datenbank.

Bei unserer Analyse haben wir folgende Anforderungen an die Datenspeicherung festgestellt:

1. Starke Konzentration auf die Suche, einschließlich unscharfer Suche
2. Kein Schreiben von Daten, außer einer periodischen Aktualisierung des gesamten Datenspeichers
3. Daten werden immer mit der gleichen redundanten Struktur geliefert
4. Teile der Daten haben eine flexible Struktur

Aufgrund der oben genannten Punkte kamen wir zu dem Schluss, dass eine relationale Datenbank kein optimales System für die Speicherung der Daten der Tochtergesellschaften ist. Stattdessen entschieden wir uns für ElasticSearchder es ermöglicht, strukturierte Daten zu speichern und effizient zu durchsuchen. Bei jedem Import erstellen wir einen völlig neuen Index (eigentlich 3, einen für jede unterstützte Sprache).

10. Strategie der Stapelersetzung

Wie wir im vorigen Artikel erörtert haben, kann die Ersetzung einer so großen Anwendung Monate oder sogar Jahre dauern. Sie können nicht einfach aufhören, das Altsystem zu unterstützen, während Sie das neue System entwickeln. Sie brauchen eine Strategie.

Unser Fall: Grob gesagt, sind wir wie folgt vorgegangen.

Einrichtungsphase:

• Implementierung eines neuen Importers, Import von Daten über die API des Altsystems
• Implementierung einer neuen API
• Implementierung eines neuen Clients auf der Grundlage der neuen API

Migrationsphase:

• Inkrementelle Ersetzung von Importen aus der alten API durch Importe aus den ursprünglichen Datenquellen
• Parallel dazu schrittweise Unterstützung der Beteiligten bei der Umstellung auf eine neue API oder auf neue Kunden

Sobald alle Daten aus den ursprünglichen Datenquellen importiert sind und alle Beteiligten auf den neuen Stack migriert haben, kann der alte Stack abgeschafft werden.