Altlasten im Code bereinigen

Altlasten entfernen.
Ohne dass etwas kaputtgeht.

In vielen gewachsenen Anwendungen weiß niemand mehr genau, welcher Code noch gebraucht wird. Also traut sich keiner, etwas zu löschen, und jede Änderung wird teurer als die letzte. Ich finde heraus, was tatsächlich genutzt wird, und entferne den Rest Schritt für Schritt.

Bereinigung besprechen

Stefan Pilz · PHP-Entwicklung und Bestandsanalyse · 100 % remote

IllustrationErst verstehen, dann aufräumen.

LEISTUNG IM ÜBERBLICK

Was Legacy-Code-Bereinigung bedeutet

Legacy-Code-Bereinigung bedeutet, ungenutzten Code, überflüssige Abhängigkeiten und veraltete Funktionen aus einer bestehenden Anwendung zu entfernen, ohne den laufenden Betrieb zu gefährden. Grundlage ist keine Vermutung, sondern ein Nachweis, welcher Code tatsächlich ausgeführt wird.

Über Jahre sammelt sich in jeder Anwendung Ballast an: Funktionen für Kunden, die es nicht mehr gibt, auskommentierte Blöcke, Ordner mit Namen wie _alt oder backup2, Bibliotheken, die niemand mehr verwendet, und Workarounds für Probleme, die längst gelöst sind. Wer den Code geschrieben hat, ist oft nicht mehr im Unternehmen.

Das Ergebnis: Jede Änderung dauert länger, weil erst geklärt werden muss, was sie beeinflusst. Updates werden riskant, ungenutzte Bibliotheken bleiben als Sicherheitsrisiko im System, und neue Entwickler brauchen Wochen, um sich zurechtzufinden.

Ihr Ansprechpartner: Stefan Pilz · Stefan Pilz Ltd. · Zusammenarbeit 100 % remote

KONKRETER LEISTUNGSUMFANG

So wird aus Unsicherheit ein klarer Plan

Herausfinden, was wirklich genutzt wird

Statische Analyse zeigt, welcher Code nirgends aufgerufen wird und welche Composer-Pakete ungenutzt sind. Das reicht aber nicht, denn in PHP wird vieles erst zur Laufzeit zusammengesetzt. Deshalb setze ich zusätzlich unauffällige Markierungen in verdächtige Codeteile, die protokollieren, ob sie im Betrieb noch ausgeführt werden. Dazu kommen Zugriffsprotokolle des Servers und eine Liste aller Cronjobs und Importe.

Wichtig ist ein ausreichend langer Beobachtungszeitraum: Code, der nur zum Monatsende oder einmal im Jahr läuft, etwa für einen Jahresabschluss, darf nicht versehentlich als ungenutzt gelten.

Absichern, bevor gelöscht wird

Gibt es noch keine Versionsverwaltung, richte ich sie als Erstes ein. Damit ist jede Änderung nachvollziehbar und rückgängig zu machen. Für die geschäftskritischen Abläufe schreibe ich Tests, die das heutige Verhalten festhalten. So fällt sofort auf, wenn eine Bereinigung etwas verändert, das erhalten bleiben soll.

Entfernen, vereinfachen, dokumentieren

Ich entferne ungenutzten Code in kleinen Schritten, die jeweils einzeln live gehen können. Unübersichtliche Teile, die weiter gebraucht werden, vereinfache ich so, dass sie lesbar und testbar werden. Jede Entscheidung wird dokumentiert, damit auch später nachvollziehbar ist, warum etwas entfernt wurde.

TYPISCHE ALTLASTEN

Was sich in gewachsenen Anwendungen ansammelt

Die folgenden Punkte beschreiben typische Altlasten, keine dokumentierten Kundenprojekte.

Dateien und Ordner, die niemand mehr kennt

Kopien wie index_alt.php, Testskripte im öffentlichen Verzeichnis oder ganze Ordner mit alten Versionen. Sie sind nicht nur Ballast, sondern können auch ungewollt von außen erreichbar sein.

Bibliotheken ohne Verwendung

Pakete, die einmal für eine Funktion installiert wurden, die es nicht mehr gibt. Sie blockieren Updates und bleiben mit ihren Sicherheitslücken im System, obwohl sie niemand braucht.

Sonderfälle für vergangene Anforderungen

Bedingungen für einzelne Kunden, Aktionen oder Schnittstellen, die längst abgeschaltet sind. Jede davon macht den Code schwerer verständlich und Änderungen riskanter.

ERGEBNISSE & ABGRENZUNG

Ihr Ergebnis und was wir vorab klären

Ihre vereinbarten Ergebnisse

Welche Ergebnisse zum Auftrag gehören, halten wir vor Beginn fest. Je nach vereinbartem Umfang sind das:

Bestandsliste mit genutzten, ungenutzten und unklaren Codeteilen und Abhängigkeiten
Versionsverwaltung und Tests für die wichtigsten Abläufe, soweit noch nicht vorhanden
Entfernter Ballast in nachvollziehbaren, einzeln rückgängig zu machenden Schritten
Dokumentation der Entscheidungen und der verbleibenden offenen Punkte

Was wir vorab klären

Wie viel sich entfernen lässt, zeigt erst die Analyse. Für Codeteile, deren Nutzung sich im Beobachtungszeitraum nicht eindeutig klären lässt, entscheiden wir gemeinsam, ob sie bleiben, archiviert oder mit Rücksprache entfernt werden. Ohne Zugriff auf Quellcode und Server-Protokolle ist ein belastbarer Nachweis nicht möglich.

Aufwand und Kosten

Für eine erste Einschätzung helfen eine grobe Beschreibung der Anwendung, ihr Alter und die eingesetzte PHP-Version. Den Umfang der Analyse und der Bereinigung vereinbaren wir vorab.

ZUSAMMENARBEIT

So läuft eine Bereinigung ab

Zugang und Überblick

Ich verschaffe mir einen Überblick über Code, Server, Cronjobs und Schnittstellen und kläre mit Ihnen, welche Abläufe geschäftskritisch sind.

Beobachten

Markierungen und Protokolle sammeln über einen vereinbarten Zeitraum Daten, welche Codeteile tatsächlich genutzt werden.

Aufräumen

Ungenutztes wird in kleinen Schritten entfernt, jede Änderung getestet und einzeln übernommen.

Übergeben

Sie erhalten eine aufgeräumte Anwendung, eine Dokumentation und eine Grundlage für künftige Updates.

PASSENDE THEMEN

Hängt oft zusammen

Datenbank bereinigen

Verwaiste Tabellen, Protokolle und Altdaten mit Sicherung und Rückweg entfernen.

PHP-Update

Code an PHP 8.4 oder 8.5 anpassen, bevor die alte Version keine Sicherheitsupdates mehr bekommt.

Symfony-Update

Von älteren Versionen über die LTS-Releases auf Symfony 7.4 oder 8 aktualisieren.

FRAGEN & ANTWORTEN

Fragen zur Bereinigung von Legacy-Code

Was, wenn wir etwas löschen, das doch gebraucht wird?

Genau deshalb arbeite ich mit Nachweis, kleinen Schritten und Versionsverwaltung. Jede Löschung lässt sich gezielt rückgängig machen. Unklare Teile werden nicht einfach entfernt, sondern zuerst beobachtet oder mit Ihnen abgestimmt.

Unser ursprünglicher Entwickler ist nicht mehr erreichbar. Ist das ein Problem?

Nein, das ist der häufigste Fall. Die Analyse stützt sich auf den Code, die Protokolle und das Wissen der Menschen, die mit der Anwendung arbeiten, nicht auf Erinnerungen des ursprünglichen Entwicklers.

Muss dafür alles neu geschrieben werden?

Nein. Ziel ist es, die vorhandene Anwendung zu erhalten und verständlicher zu machen. Ein Neubau ist nur dann sinnvoll, wenn die Analyse zeigt, dass sich der Bestand nicht wirtschaftlich weiterentwickeln lässt.

Wie lange dauert die Beobachtungsphase?

Das hängt davon ab, wie oft Ihre Abläufe laufen. Für den Alltag genügen oft einige Wochen. Für Abläufe zum Monats- oder Jahresende legen wir den Zeitraum entsprechend fest oder klären die Nutzung im Gespräch.

Wir haben keine Versionsverwaltung. Geht das trotzdem?

Ja. Die Einrichtung einer Versionsverwaltung ist dann der erste Schritt. Ab diesem Moment ist jede Änderung an Ihrer Anwendung nachvollziehbar, auch über die Bereinigung hinaus.

NÄCHSTER SCHRITT

Welche Anwendung ist Ihnen über den Kopf gewachsen?

Beschreiben Sie kurz, was die Anwendung leistet, wie alt sie ist und wo es bei Änderungen hakt. Ich melde mich mit einem Vorschlag, wie wir die Bestandsaufnahme angehen.

Ihre Anfrage geht direkt an mich, Stefan Pilz. Umfang und Kosten klären wir vor der Beauftragung.

So geht es nach Ihrer Anfrage weiter

Ausgangslage klären
Ich lese Ihre Anfrage und melde mich bei Ihnen. Gemeinsam klären wir Ziel, Rahmen und offene Fragen.
Sinnvollen Einstieg bestimmen
Je nach Vorhaben starten wir mit einer gezielten Umsetzung oder einer vorab vereinbarten Analyse.
Umfang und Angebot abstimmen
Sie erfahren, welche Leistungen und Ergebnisse vereinbart werden. Aufwand und Kosten klären wir vor der Beauftragung.