Fünf Dinge, die Sie beachten sollten, bevor Sie eine komplexe Legacy-Webanwendung ersetzen

Unser Kunde beauftragte uns, seine Altanwendung durch ein moderneres Technologiepaket unserer Wahl zu ersetzen.

Auf den ersten Blick mag es so klingen, als könne man sich einfach die Technologie aussuchen, die man schon immer nutzen wollte, aber es ist viel komplexer als das.

Die Anwendung importierte regelmäßig Daten aus verschiedenen Quellen, einige davon täglich und andere stündlich. Sie ermöglichte einen Nur-Lese-Zugriff auf die Daten über eine REST-API, die von verschiedenen Beteiligten direkt genutzt wurde. Außerdem verfügte sie über mehrere Client-UIs und Widgets mit unterschiedlichen Einstellungen und Themen, die auf verschiedene Weise in eine Reihe von Websites eingebettet waren.

Unsere Aufgabe bestand darin, die Wartung der alten Anwendung zu übernehmen und sie vollständig zu ersetzen und zu modernisieren. Dabei mussten wir sicherstellen, dass sich alle Beteiligten weiterhin auf die Dienste der Anwendung verlassen konnten und die Umstellung so reibungslos wie möglich verlief.

Dieses große Projekt hat uns geholfen, unser Fachwissen und unsere Erfahrung erheblich zu erweitern. Wir haben uns entschlossen, eine Fallstudie über dieses große Projekt zu veröffentlichen, in der wir in einer Reihe von Artikeln darlegen, was wir gelernt haben und was wir bei der Umstellung einer großen Codebasis für gute Praktiken halten.

In diesem ersten Artikel werden wir einige Überlegungen anstellen, die Sie anstellen müssen, wenn Sie als Unternehmen ein ähnliches Projekt in Angriff nehmen wollen.

1. Seien Sie sicher, dass es sich lohnt

Für ein Unternehmen ist es immer mit einem gewissen Risiko verbunden, eine extern entwickelte Codebasis zu übernehmen und neu zu implementieren.

Denken Sie daran, was Robert C. Martin sagt über Redesigns in seinem klassischen Buch "Clean Code":

«Die Geschäftsleitung will die Ressourcen für eine völlige Neugestaltung des Projekts nicht aufwenden, aber sie kann nicht leugnen, dass die Produktivität schrecklich ist. Schließlich beugen sie sich den Forderungen der Entwickler und genehmigen das große Redesign in der Luft. [...] Jetzt [...] befinden sich zwei Teams in einem Wettlauf, [von denen] eines ein neues System bauen muss, das alles kann, was das alte System kann. Und nicht nur das: Sie müssen mit den Änderungen Schritt halten, die ständig am alten System vorgenommen werden. Dieser Wettlauf kann sich sehr lange hinziehen. Ich habe schon erlebt, dass es 10 Jahre dauert. Und wenn es dann fertig ist, sind die ursprünglichen Mitglieder des Tiger-Teams längst weg, und die jetzigen Mitglieder verlangen, dass das neue System neu gestaltet wird, weil es so ein Chaos ist.»

Dennoch gibt es gute Gründe, sich einer solchen Herausforderung zu stellen:

• Der Legacy-Stack passt nicht zu den Qualitätsstandards, dem Kern-Know-how oder der Philosophie Ihres Unternehmens, so dass Sie ihn nicht einfach übernehmen und die aktuelle Codebasis beibehalten können.
• Am Ende zahlt es sich aus, wenn Sie sich das Wissen aneignen, das in den alten Stack eingebettet ist, und die Verantwortung für die Wartung der neuen Codebasis übernehmen, mit der Möglichkeit einer langfristigen Beziehung zu Ihrem Kunden.

2. Sie müssen sich um den Übergang kümmern

Sie werden das alte System verstehen müssen und wahrscheinlich neue Funktionen und Korrekturen hinzufügen, während Sie an der Entwicklung des neuen Systems arbeiten. Die Aktionäre werden Unterstützung brauchen, es wird Widerstand geben und es wird zu Verzögerungen kommen. Wenn es eine Herausforderung bei einem solchen Projekt gibt, dann die, dass es viele bewegliche Teile, und der Teufel steckt im Detail des Zusammenspiels dieser Teile.

Und - Sie haben R. C. Martin gehört - eine solche Operation könnte eine Los von Zeit - Monate oder sogar Jahre. Während dieser langen Zeitspanne werden nur Menschen, die sich wirklich kümmern, geduldig genug sein, hart arbeiten, um alle Details im Kopf zu behalten, an Konsequenzen denken, Erinnerungen setzen und die richtigen Leute zur richtigen Zeit informieren.

3. Verteilen Sie Ihr Team gut

Denken Sie daran, dass die Mitarbeiter des alten Systems gegen ihre eigenen Interessen arbeiten müssen - sie müssen sich selbst überflüssig machen! Es ist daher ratsam, dass alle Mitarbeiter an beiden Projekten beteiligt sind, d.h. nicht nur für die Wartung des Altsystems zuständig sind, sondern auch aktiv an der Umstellung mitwirken. Bei einem Team von etwa 6 Personen, die für diesen speziellen Kunden arbeiteten, war 1 Person für das alte System und die Migration (+ 1 Backup) zuständig, während der Rest des Teams am neuen Stack arbeitete.

4. Kommunizieren, kommunizieren, kommunizieren

Sie müssen alle Beteiligten mit auf die Reise nehmen. Sie haben ihre eigenen Projekte mit ihren eigenen, sehr realen Anforderungen, Budgets und Fristen laufen. Sie wollen nicht unbedingt eine Änderung (oder wissen, dass sie es wollen). Sie müssen in der Lage sein, die Vorteile des neuen Systems zu vermitteln, ihnen Links zu Dokumentationen zu schicken, ihnen angepasste Codeschnipsel zukommen zu lassen, sie an Fristen zu erinnern und vor allem bereit zu sein, sich oft zu wiederholen.

5. Zeichnen Sie eine Linie

Das Gegenstück zum vorherigen Abschnitt. Sie wollen nicht, dass die Mitarbeiter Ihres Teams für immer mit einem Altsystem feststecken (oder dass sie aus Frustration mit halbfertiger Arbeit aufhören). Wenn Sie ein solches Projekt übernehmen, sollten Sie Ihrem Kunden gegenüber deutlich machen, wie weit in der Zukunft Sie bereit sind, an dem Altsystem zu arbeiten. Legen Sie gemeinsam mit dem Kunden grobe Termine für die folgenden Meilensteine fest:

• Offizielle Abschaffung des alten Systems
• Keine neuen Funktionen und Änderungen
• Keine Fehlerbehebungen
• Ende der Unterstützung
• Abschaltung des Altsystems

Wenn es sich um ein wirklich komplexes Projekt handelt, müssen Sie mit einigen Verzögerungen rechnen. Aber scheuen Sie sich nicht, sie daran zu erinnern und weiter auf einen erfolgreichen Übergang hinzuarbeiten.