Refactoring von Legacy-Software: Von Herausforderungen zu Chancen

In diesem Artikel erfahren Sie, wie wir mit der Internationalisierung eines Logistikmanagementsystems (OMS) umgehen und welche Herausforderungen die Integration mit neuen E-Commerce-Plattformen mit sich bringt. Das System wurde 2018 entwickelt, um den Bestellvorbereitungsprozess eines boomenden E-Commerce-Unternehmens zu optimieren und eine effiziente Integration mit verschiedenen Logistikbetreibern zu erm?glichen. Es wurde mit PHP (Symfony), MySQL, Socket.io und jQuery erstellt und deckt den gesamten Prozess von der Verpackung bis zum Versand ab, einschlie?lich Funktionen wie Auftragsverfolgung, Kurierverbindungen, Etikettengenerierung und Leistungsmetriken für die Auftragsvorbereitung.

Die Anh?ufung technischer Schulden

Dieses System funktionierte viele Jahre lang gut, aber als das Unternehmen wuchs, wurden seine Grenzen immer offensichtlicher. Besonders besorgniserregend sind technische Schulden, die mehrere Ebenen eines Projekts betreffen. Hinsichtlich der technischen Infrastruktur l?uft die Anwendung auf veralteten Frameworks und Basissprachversionen:

• Symfony-Version (4.0) ist keine Langzeit-Support-Version (LTS) und erh?lt ab Januar 2019 keine Sicherheitsupdates mehr.
• Auch PHP 7.1 hat seinen Lebenszyklus beendet und dem System fehlen kritische Sicherheitsupdates.

Neben veralteten Versionen weist das Projekt auch gravierende M?ngel in den Grundlagen der Softwareentwicklung auf:

• Fehlende oder unzureichende Tests: Ein Mangel an automatisierten Tests (Einheiten-, Integrations- und End-to-End-Tests) behindert nicht nur die frühzeitige Erkennung von Fehlern, sondern führt auch dazu, dass ?nderungen potenziell die Stabilit?t gef?hrden des Systems.
• Fehlende Codierungsstandards: Die Codebasis folgt keinen dokumentierten Mustern oder Standards, und selbst wenn es solche gibt, entsprechen sie nicht den Best Practices der Branche. Dies erschwert sowohl die Wartung als auch die Einbindung neuer Entwickler in das Projekt.
• Unzureichende Dokumentation: Die vorhandene Dokumentation ist sp?rlich und oft unvollst?ndig. Dies betrifft nicht nur die technische Entwicklung, sondern auch das Verst?ndnis der im Code implementierten Gesch?ftsprozesse.
• Unvollst?ndige Versionskontrolle: Dem Git-Verlauf fehlt eine Erkl?rung, die Commit-Granularit?t ist grob, Nachrichten folgen keinen Konventionen und es fehlen Hintergrundinformationen zu den vorgenommenen ?nderungen. Dies macht es schwierig, die Entwicklung des Codes und der im Laufe der Zeit getroffenen Entscheidungen zu verstehen.

Die Anh?ufung technischer Schulden stellt nicht nur eine Bedrohung für die Stabilit?t und Sicherheit des Systems dar, sondern auch:

• Die Entwicklungsgeschwindigkeit neuer Funktionen wurde reduziert
• Erh?htes Risiko der Einführung von Fehlern
• Die Schwierigkeit für neue Mitglieder, dem Team beizutreten, wurde erh?ht
• Erh?hte Wartungskosten
• Erschwert die Problemdiagnose und -l?sung

Strukturelle Einschr?nkungen

Die ursprüngliche Architektur hatte Kopplungsprobleme, die ihre Flexibilit?t und Skalierbarkeit ernsthaft beeintr?chtigten:

• V?llig abh?ngig von der Haupt-E-Commerce-Plattform: Die Anwendung kann nicht unabh?ngig ausgeführt werden und alle Logistikvorg?nge sind direkt von den Daten und Prozessen der E-Commerce-Plattform abh?ngig. Dies bedeutet, dass ?nderungen an der Hauptplattform die Funktionalit?t des Systems beeintr?chtigen k?nnen.
• Gemeinsam genutzte Datenbank verursacht Leistungsprobleme: Logistikanwendungen und E-Commerce-Plattformen verwenden dieselbe Datenbank, was zu Leistungsproblemen führt, insbesondere in Spitzenlastzeiten für beide Anwendungen. Darüber hinaus erschwert diese Konfiguration die Berechtigungsverwaltung, da jeder Zugriff auf die Datenbank wichtige Daten anderer Systeme gef?hrden kann.
• Kann nicht eigenst?ndig ausgeführt werden: Diese App ist nur für die Ausführung mit E-Commerce-Plattformen konzipiert. Dies schr?nkt nicht nur die Portabilit?t ein, sondern verhindert auch das Testen in einer isolierten Umgebung oder die Migration auf andere Plattformen. Seine Abh?ngigkeiten sind nicht richtig gekapselt, jeder Isolationsversuch würde gro?e und kostspielige ?nderungen am gesamten System erfordern und das Single Responsibility Principle (SRP) wird in der Hauptklasse nicht eingehalten.
• Schwierigkeiten bei der Implementierung neuer Funktionen: Die mangelnde Einhaltung des Open/Closed-Prinzips (OCP) und des Liskov-Substitutionsprinzips (LSP) behindert die Weiterentwicklung des Systems erheblich. Neue Funktionen erfordern ?nderungen am vorhandenen Code, wodurch das Risiko der Einführung von Regressionen steigt. Darüber hinaus machen direkte Abh?ngigkeiten zwischen Modulen die Einhaltung des Dependency Inversion Principle (DIP) nahezu unm?glich.

Diese strukturellen Einschr?nkungen verringern nicht nur die Wartbarkeit und Skalierbarkeit des Systems, sondern erh?hen auch die mit jeder ?nderung oder Weiterentwicklung verbundenen Risiken, wodurch die Anwendung in einem technisch fragilen und strategisch anf?lligen Zustand bleibt.

Entwicklungsmanagement und strategische Ausrichtung

Eine der gr??ten Herausforderungen ist nicht nur technischer, sondern auch strategischer Natur. W?hrend die externe Entwicklung funktional korrekt ist, gibt es erhebliche organisatorische Einschr?nkungen:

• Abgekoppelt von der globalen Strategie: Die Entwicklung erfolgt in Silos ohne ein vollst?ndiges Verst?ndnis der internen Ziele und Prozesse des Unternehmens. Dies führt zu Funktionen, die zwar technisch korrekt sind, aber nicht immer den tats?chlichen Anforderungen des Unternehmens entsprechen.
• Mangelnde strategische Priorisierung: Bei der Implementierung neuer Funktionen fehlt ein klarer Bewertungs- und Priorisierungsprozess. Es besteht kein Zweifel, ob eine Funktion wirklich notwendig ist, ob sie die beste M?glichkeit ist, sie zu implementieren, oder ob es eine effizientere Alternative gibt.
• Reaktive Entwicklung vs. Proaktive Entwicklung: Die Entwicklung folgt in erster Linie einem reaktiven Modell und geht auf unmittelbare Bedürfnisse ein, ohne langfristige Auswirkungen oder potenzielle Synergien mit anderen Prozessen im Unternehmen zu berücksichtigen.
• Fehlender Validierungsprozess: Das Fehlen eines strukturierten überprüfungs- und Validierungsprozesses führt dazu, dass Funktionen zwar funktionieren, aber nicht immer die beste L?sung für den Endbenutzer oder die Gesamtziele des Unternehmens bieten.

Diese Situation ist auf lange Sicht unhaltbar, weil sie:

• Dies führt dazu, dass Produkte zunehmend vom tats?chlichen Bedarf abweichen
• Behindert die Integration mit anderen Unternehmenssystemen und -prozessen
• Erschwert strategische Entscheidungen über Produkte
• Schr?nkt die F?higkeit des Teams zur Innovation und kontinuierlichen Verbesserung ein

Auswirkungen der Grundkosten

Ein oft übersehener, aber besonders wichtiger Aspekt in diesem Projekt sind die Grundkosten, die meiner Meinung nach ein Schlüsselkonzept in der Softwareentwicklung sind und sich auf die Kosten beziehen, die dafür anfallen, ein System am Laufen zu halten, auch ohne neue Funktionen hinzuzufügen oder minimale Verbesserungen vorzunehmen.

In unserem Fall umfassen die Grundkosten alle Kosten im Zusammenhang mit der Wartung veralteter Framework- und Sprachversionen, der Behebung von Notf?llen aufgrund der Anh?ufung technischer Schulden, der Verwaltung von Abh?ngigkeiten mit anderen Systemen, der Anpassung an gekoppelte Architekturen sowie Kosten für Dom?nenkenntnisse, die aufgrund unzureichenden Verst?ndnisses entstehen . All dies verbraucht einen erheblichen Teil der verfügbaren Ressourcen und wirkt sich direkt auf die F?higkeit aus, in Innovation und kontinuierliche Verbesserung zu investieren.

Obwohl dieser Faktor nicht ausschlaggebend für unsere Entscheidung zur Internalisierung der Entwicklung war, hatte er doch einen gro?en Einfluss auf die Erstdiagnose des Projekts. Bei der Bewertung der Nachhaltigkeit eines Systems werden die Grundkosten oft au?er Acht gelassen, aber in diesem Fall zeigt es deutlich, dass aktuelle Strategien auf lange Sicht nicht nachhaltig sind. Darüber hinaus wird jeder Versuch, die bestehende Struktur beizubehalten, wie wir in den folgenden Artikeln sehen werden, die Grundkosten im Laufe der Zeit exponentiell erh?hen.

Für eine detailliertere Erl?uterung grundlegender Kostenkonzepte und ihrer Bedeutung wird empfohlen, den Originalartikel von Eduardo Ferro zu lesen.

Wendepunkt: Neue Herausforderungen und strategische Entscheidungen

In jedem Refactoring-Projekt gibt es mehrere Strategien, die angewendet werden k?nnen, und oft st??t man auf das Dilemma: Würgefeige oder Big-Bang-Rewrite.

Die anf?ngliche technische Entscheidung bestand darin, innerhalb desselben Legacy-Projekts mit dem Strangler Pattern zu arbeiten, einem Ansatz, der die Entwicklung eines neuen Moduls oder Systems beinhaltet, das nach und nach Teile des alten Systems ersetzt. Diese Strategie erm?glicht es uns, parallele ?nderungen vorzunehmen, Risiken zu reduzieren und die aktuelle Funktionalit?t aufrechtzuerhalten und gleichzeitig eine st?rkere Grundlage für die Unterstützung zukünftiger Funktionen zu schaffen.

Aus gesch?ftlicher Sicht stellt diese Option jedoch ein überm??iges Risiko für das bestehende System dar (das bereits betriebsbereit ist und seine Funktionen erfüllt). Wir haben beschlossen, das bestehende Projekt nicht zu berühren und stattdessen eine eigenst?ndige Anwendung zu entwickeln, um den neuen Anforderungen gerecht zu werden.

Diese Verschiebung führte dazu, dass wir die bestehende Codebasis verzweigten, eine Entscheidung, die technisch machbar war, aber bestimmte Nachteile mit sich brachte:

• Duplizierung von Codebasen: Jetzt müssen zwei separate Codebasen gepflegt werden.
• Datenbanktrennung: Datenstrukturen müssen für jedes System kopiert und angepasst werden.
• Infrastrukturreplikation: Erfordert die Bereitstellung unabh?ngiger Server und die Gew?hrleistung einer angemessenen Beobachtbarkeit für jedes System.
• Erh?hte kognitive Belastung des Teams: All diese Duplizierungen erfordern zus?tzlichen Aufwand, um die Konsistenz zwischen den beiden Systemen aufrechtzuerhalten, wodurch die Komplexit?t des Teams und das Fehlerrisiko steigen.

Dieser Ansatz erm?glicht es uns, unabh?ngige L?sungen zu finden, die Stabilit?t bestehender Systeme sicherzustellen und gleichzeitig ein Projekt zu entwickeln, das auf neue strategische Ziele ausgerichtet ist. Allerdings ist eine detaillierte Analyse der Vor- und Nachteile notwendig, um diese Herausforderung souver?n planen und meistern zu k?nnen. Darüber hinaus haben wir mit der Gesch?ftsebene einen Konsens erzielt, die Funktionalit?t nicht zu erweitern und den Projektrückstand bis zum Abschluss der Migration auf die neue E-Commerce-Plattform streng zu kontrollieren.

Fazit und n?chste Schritte

Die Entscheidung, Legacy-Software zu verinnerlichen und neu zu schreiben, ist nie einfach, insbesondere wenn die Software in der Lage ist, ihre Aufgabe zu erfüllen. Das Sprichwort ?Wenn es funktioniert, fassen Sie es nicht an“ wird es immer geben. Allerdings braucht es manchmal einen Schritt zurück, um zwei Schritte vorw?rts zu machen.

In den folgenden Artikeln dieser Reihe werden wir untersuchen, wie wir auf diese Herausforderungen reagiert haben, welche technischen und strategischen Entscheidungen wir getroffen haben und wie wir diese Herausforderungen in Chancen für Verbesserungen und Teamentwicklung umgewandelt haben.

Das obige ist der detaillierte Inhalt vonVom Software-Legacy zur strategischen Chance: Der Ausgangspunkt (I). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!