Bei WATA Factory wurden wir bereits bei mehreren Gelegenheiten mit der Modernisierung von Projekten mit Legacy–Code konfrontiert. In diesem Artikel sprechen wir darüber, wie wir vorgegangen sind und wie wir die Situation angegangen sind.
Um in das Thema einzusteigen, müssen wir uns folgende Fragen stellen: (1) Was verstehen wir unter einem Legacy-Projekt? (2) Wenn es funktioniert, warum sollen wir es ändern? (3) Wie machen wir das? Schauen wir es uns an!
Was verstehen wir unter einem Legacy-Projekt?
Für uns ist ein Legacy–Code (oder Spaghetti-Code) ein Code, bei dem das, was wir für gute Entwicklungspraktiken (Clean Code) halten, weder angewendet wird, noch SOLID-Prinzipien folgt und darüber hinaus keine gute (oder überhaupt gar keine) Testabdeckung hat.
In der Regel handelt es sich bei diesem Code um einen alten Code, der seit mehreren Jahren in Verwendung ist (und mehr oder weniger verlässlich ist), der ohne Framework oder, in dessen Ermangelung, unter Verwendung einer alten Version eines solchen entwickelt wurde (z.B. Symfony 2).
Wenn es funktioniert, warum sollen wir es ändern?
Das ist eine sehr gute Frage, vor allem weil man in unserer Branche oft (manchmal zu oft) hört: was funktioniert, das ändert man nicht.
Die Antwort auf diese Frage ist nicht einfach. Wir sollten die Modernisierung (oder auch nicht) unter dem Aspekt der Nachhaltigkeit und der Stimmigkeit mit den Praktiken, die täglich im Unternehmen durchgeführt werden, in Betracht ziehen.
- Nachhaltigkeit, denn wenn wir von einem laufenden Projekt sprechen erreichen wir jedes Mal, wenn eine neue Entwicklung gemacht wird, nur, dass wir das Monster weiter füttern. Es wird die Zeit kommen in der diese Modernisierung, von der wir gesprochen haben, praktisch unmöglich sein wird, ohne viel Zeit und damit auch Geld zu investieren.
- Stimmigkeit, denn wenn die neuen Projekte einer Reihe von Qualitätsstandards, Einheits- oder Integrationstests usw. folgen, warum werden wir dann laufende Projekte haben, bei denen diese Praktiken nicht angewendet werden, nur weil es sich um ein langfristiges Projekt handelt?
Wie machen wir das?
Wenn wir an diesem Punkt angekommen sind, dann weil wir davon überzeugt sind, dass wir unseren Code erneuern wollen.
Bei WATA Factory arbeiten wir mit Symfony, also werden wir in unserem Fall ein Projekt zu diesem Framework erstellen und den Legacy–Code darin integrieren.
Wenn wir neue Funktionen erarbeiten, werden wir diese im Rahmen des Symfony-Projekts entwickeln. Die alten Funktionen werden in dem, was wir LegacyBundle nennen werden, enthalten sein. Wir setzen diesen Prozess um, indem wir die in diesem Leitfaden (veröffentlicht von Yannick de Lange) aufgeführten Schritte befolgen.
Dieses Bundle wird das gesamte Legacy-Projekt enthalten, und durch Routing werden wir unsere neuen Endpunkte auf den alten Code umleiten, so dass alles weiterhin funktioniert.
Diese Struktur gibt uns die Möglichkeit, nicht das gesamte Projekt auf einmal migrieren zu müssen, mit der damit verbundenen Zeit und dem Risiko, das dies mit sich bringt. Wenn wir bestehende Funktionalitäten modifizieren, müssen wir daran denken sie aus dem Legacy Bereich herauszunehmen und in den neuen Bereich einzufügen. Dies wird dazu führen, dass der Legacy-Teil im Laufe der Zeit immer kleiner wird.
Wenn aus irgendeinem Grund Symfony nicht verwendet wird und der Legacy–Code und der neue Code nicht nebeneinander existieren können, empfehlen wir dem Leitfaden zu folgen, der in dem Buch Modernizing Legacy Applications in PHP von Paul M. Jones enthalten ist.
Paul M. stellt uns Richtlinien zur Modernisierung des Projekts zur Verfügung, einschließlich Autoload, Refactoring des Codes usw.
