„Wir haben zu viel Angst, dieses System anzufassen.“
Dieser Satz ist fast garantiert etwas, das man früher oder später hört, wenn man mit technologiebezogenen Systemen arbeitet. Die Gründe dafür variieren von Unternehmen zu Unternehmen, laufen aber oft auf Aussagen hinaus wie „Wir haben keine Zeit, uns darum zu kümmern“ oder „Der ursprüngliche Entwickler hat die Firma verlassen“. Ein weiterer häufiger Grund ist der Start eines neuen Projekts, ohne das nötige Fundament zu legen. Dadurch gerät das Entwicklerteam ständig ins Hintertreffen, anstatt mit Selbstvertrauen ein modernes System zu entwickeln.
Eine typische Reaktion darauf ist, dass Entwickler anfangen, „Microservices“ zu bauen, weil ihnen das für eine gewisse Zeit erlaubt, auf einem neuen System zu arbeiten und sichtbare Fortschritte zu machen. Doch mit der Zeit schleicht sich wieder Komplexität ein, und man hat ein Monolith erschaffen, das viele andere Systeme an sich bindet. Irgendwann müssen fünf verschiedene Systeme und drei Datenbanken aktualisiert werden, um ein Release zu veröffentlichen. Jede neue Version bringt größere Bugs mit sich. Das Entwicklerteam spricht wieder von einem neuen Microservice – und alles beginnt von vorn. Stillstand!
Die gute Nachricht ist: Das lässt sich lösen! Die schlechte: Es erfordert Zeit, Planung und Einsatz. Das ist nichts, was man seinem Team einfach aufzwingen kann. Man braucht die Zustimmung aller Beteiligten sowie den Mut, Neues zu lernen. Die Modernisierung eines Altsystems kann beängstigend sein, weil sie das „Vertraute“ aus dem Arbeitsalltag entfernt – ist aber entscheidend, um diese Arbeit auch in Zukunft noch machen zu können.
Ich kann euch bei diesem Prozess helfen!
Ich unterstütze euer Team dabei, ein veraltetes PHP-System kontrolliert zu modernisieren. Das kann bedeuten, dass der PHP-Code lediglich als REST JSON API dient und das Frontend durch moderne Technologien wie React oder Vue gerendert wird – oder dass ich euch helfe, es auf die neueste PHP-Version umzustellen.
Meine Strategie ist in verschiedenen Unternehmen meist dieselbe: Ohne ein solides Fundament kann euer Team sein Potenzial nicht entfalten. Deshalb beginnt alles mit dem Aufbau eines zuverlässigen und robusten CI/CD-Prozesses, der euren Entwicklern kontinuierliches Feedback während der Entwicklung bietet.
Der erste Schritt, noch bevor wir Code ändern, ist es, einen reproduzierbaren Build eures Systems im aktuellen Zustand zu erstellen. Das bedeutet: Wir müssen in der Lage sein, euer System sauber zu reproduzieren und auf einem anderen Rechner zum Laufen zu bringen. Am Ende dieses Schritts kann euer Team das gesamte System lokal auf dem eigenen Rechner ausführen – alle mit identischen Einstellungen. Der Satz „Bei mir funktioniert es“ gehört der Vergangenheit an.
Indem wir die Testpyramide umkehren, beginnen wir damit, die wichtigsten Nutzerpfade schrittweise zu testen. So gewinnen wir Vertrauen und lernen, wie wir unsere Arbeit überprüfen, bevor wir sie ausliefern. Konkret bedeutet das: Ein Browser wird geöffnet und klickt automatisch durch euer System.
Dieser Teil ist entscheidend, da er eine sehr breite Testabdeckung bietet. Wenn wir Teile des Systems kaputt machen, merken wir das schnell – ohne uns sofort mit den Details einzelner Unit-Tests befassen zu müssen. Wichtig ist hier nur: Funktionieren der Warenkorb und der Bestellprozess für eure Nutzer?
Es ist erstaunlich, aber ich treffe immer noch auf Systeme ohne Paketmanager. Ein Paketmanager erlaubt es, Drittanbieter-Code zuverlässig einzubinden. Falls eure Drittanbieter-Bibliotheken einfach per Copy-Paste im Code liegen, starten wir damit, exakt dieselbe Version über den Paketmanager zu verwalten. Hoffentlich wurden an diesen Paketen keine eigenen Änderungen vorgenommen.
Nun tauchen wir etwas tiefer ins System ein. Zunächst geht es nur darum, eine Möglichkeit zu schaffen, das System über die Kommandozeile zu testen. Häufig kommt die Frage: „Warum nicht einfach bei den End-to-End-Tests bleiben?“ – Die kurze Antwort: Zeit. Einen Browser zu starten und durch das UI zu klicken, ist langsam. In der gleichen Zeit können dutzende oder hunderte Unit-Tests laufen.
Unit-Tests ermöglichen es den Entwicklern, die inneren Abläufe des Systems zu testen und sind zentral für den Aufbau des soliden Fundaments, das wir erreichen wollen.
Erst an diesem Punkt beginnt der eigentliche Prozess der Systemaktualisierung. Die vorangegangenen Schritte haben uns die Einblicke und das Feedback gegeben, die wir benötigen, um Änderungen vorzunehmen, ohne das gesamte System zu gefährden.