Vom Software-Legacy zur strategischen Chance: Der Ausgangspunkt (I)

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!