Alte Perl-Skripte, die niemand anfassen will

Ein fünfzehn Jahre altes Perl-Verzeichnis ist selten ein einzelnes System. Meist ist es ein Haufen aus Cronjobs, kopierten Hilfsprogrammen, Notfallkorrekturen, Anbindungen an Fremdsoftware und ein oder zwei Programmen, die noch jede Nacht Geld oder Kundendaten bewegen. Die erste Aufgabe ist nicht, alles neu zu schreiben. Zuerst müssen Sie nachweisen, welche Dateien am Verhalten der Produktion beteiligt sind.

Ich habe erlebt, wie Teams mit dem größten Skript begannen, dessen Syntax aufräumten und später feststellten, dass die Produktion über einen Scheduler auf einem anderen Host eine kleinere Kopie aufrief. So beschädigt ein ordentliches Modernisierungsprojekt einen hässlichen, aber funktionierenden Ablauf. Behandeln Sie das laufende System als Beweismaterial. Erstellen Sie die Bestandsaufnahme von der Ausführung aus und entscheiden Sie erst dann, was gelöscht, eingehegt, repariert oder ersetzt werden soll.

Beginnen Sie bei der Ausführung, nicht beim Quellbaum

Ein Quellbaum kann Ihnen nicht sagen, was noch läuft. Sie brauchen Belege aus Schedulern, Prozessdaten, Dienstdefinitionen, Shell-Verläufen, Programmstartern, Dateizeitstempeln und den Systemen, die die Ausgabe verbrauchen. Eine Datei kann verlassen wirken, obwohl ein Finanzjob sie weiterhin vierteljährlich aufruft. Eine andere Datei kann täglich durch einen Deployment-Prozess geändert werden, ohne je zu laufen.

Durchsuchen Sie jeden Scheduler, der Arbeit starten kann, nicht nur die Crontab des aktuellen Benutzers. Prüfen Sie systemweite Cron-Verzeichnisse, Service-Timer, Batch-Scheduler, Datenbankjobs, CI-Systeme, Verwaltungsoberflächen und den unternehmensweiten Scheduler, den der Betrieb nicht erwähnt hat. Auf Unix-artigen Hosts liefert dieser erste Durchgang brauchbare Spuren, ohne mehr Gewissheit vorzutäuschen, als die Maschine geben kann:

ps -eo pid,lstart,args | grep '[p]erl'
find /etc/cron.d /etc/cron.daily /etc/cron.hourly -type f -exec grep -nH 'perl\|\.pl' {} \;
grep -R -n 'perl\|\.pl' /etc/systemd/system /usr/lib/systemd/system
find /opt /srv /usr/local -type f \( -name '*.pl' -o -name '*.pm' \) -print

Eine typische Prozessausgabe enthält PID, Startzeit und vollständige Befehlszeile. Das ist wichtig, weil die Argumente oft den tatsächlichen Geschäftsmodus auswählen:

1842 Mon Aug 10 01:00:02 2026 /usr/bin/perl /opt/billing/bin/post.pl close

Wiederholen Sie die Prozessstichprobe über den gesamten Geschäftskalender. Eine einzelne Momentaufnahme verpasst Jobs, die nur Sekunden laufen. Halten Sie für jede beobachtete Ausführung den ursprünglichen Pfad, den Interpreterpfad, das Arbeitsverzeichnis, den Benutzer, die Argumente, die Quelle der Umgebung, den Startauslöser, die Häufigkeit, Eingaben, Ausgaben und nachgelagerte Verbraucher fest. Wenn Sie den Verbraucher nicht benennen können, ist die Bestandsaufnahme nicht fertig.

Prüfen Sie Deployment-Unterlagen als eigene Quelle. Ein Paketmanifest kann ein Skript zeigen, das außerhalb des durchsuchten Repository-Pfads abgelegt wird, und ein altes Release-Skript kann Perl-Dateien bei der Installation umbenennen oder erzeugen. Vergleichen Sie Hashes zwischen Hosts, statt gleichen Dateinamen zu vertrauen. Kennzeichnen Sie erzeugte Dateien als solche und finden Sie die Vorlage oder den Befehl, der sie erstellt. Sonst kann ein späteres Deployment unbemerkt Code zurückbringen, den Sie für stillgelegt hielten. Fragen Sie den Betrieb auch nach manuellen Aufrufen, besonders nach Korrekturen zum Monatsabschluss und Wiederholungen nach Teilfehlern. Solche Ereignisse hinterlassen oft keinen dauerhaften Scheduler-Eintrag.

Hostprotokolle können die Beweislage stärken. Prozessabrechnung, Auditprotokolle, Scheduler-Protokolle und Endgerätetelemetrie können frühere Aufrufe zeigen. Wenn diese Quellen nie aktiviert waren, vermerken Sie das in der Bestandsaufnahme. Machen Sie aus fehlenden Aufzeichnungen nicht die Behauptung, ein Skript sei tot.

Ein Aufrufgraph braucht Kanten außerhalb von Perl

Der nützliche Aufrufgraph enthält Shell, JCL, Scheduler-Einträge, Webserver-Konfiguration, Datenbankjobs, Dateieingänge und Menschen, die Runbooks befolgen. Statische Perl-Analyse deckt nur einen Teil dieses Graphen ab. Dynamisches require, zusammengesetzte Modulnamen, eval, Callbacks und durch Konfiguration gewählte Handler können selbst innerhalb der Sprache Kanten verbergen.

Beginnen Sie mit wörtlichen Referenzen und Shebangs und verfolgen Sie dann jeden bestätigten Einstiegspunkt nach außen:

grep -R -n 'use \|require \|do ' /opt/legacy-perl
grep -R -n '/opt/legacy-perl\|perl ' /opt /srv /usr/local/etc
find /opt/legacy-perl -type f -perm -u+x -exec head -n 1 {} \;

Erstellen Sie ein Register mit einer Zeile pro ausführbarer Datei. Geben Sie jeder Zeile einen Belegstatus: beobachtet, konfiguriert, referenziert oder ohne Referenz. Halten Sie diese Zustände getrennt. Ein Scheduler-Eintrag beweist eine Konfiguration, keine erfolgreiche Ausführung. Ein Dateiname in einem Runbook belegt menschliche Absicht, keine aktuelle Nutzung. Ein laufender Prozess ist ein starker Beleg, kann aber auch ein festhängender Job sein.

Erfassen Sie anschließend eingehende und ausgehende Kanten. Eingehende Kanten erklären, wie eine Ausführung beginnt. Ausgehende Kanten umfassen Module, Programme, Datenbanken, Queues, Mail-Relays, entfernte Hosts und Dateien. Halten Sie auch Datenformate fest. Eine tabulatorgetrennte Datei mit undokumentierter Spaltenreihenfolge ist eine Schnittstelle, auch wenn niemand sie so genannt hat.

Für eine Löschung brauchen Sie zwei Arten von Belegen: über einen repräsentativen Betriebszeitraum keine beobachtete oder konfigurierte eingehende Kante und keine einmalige Ausgabe, die ein anderer Prozess erwartet. Stellen Sie einen Kandidaten zuerst unter Quarantäne. Entfernen Sie das Ausführungsrecht oder verschieben Sie den Scheduler-Eintrag in eine deaktivierte, versionsverwaltete Datei und beobachten Sie, ob Erwartungen fehlschlagen. Halten Sie einen schnellen Weg zur Wiederherstellung bereit. Alter Code genießt keinen Bestandsschutz aus Sentimentalität, aber Unsicherheit ist kein Beweis.

Reproduzieren Sie den Interpreter, bevor Sie Code reparieren

Das Verhalten von Perl hängt von mehr als der .pl-Datei ab. Erfassen Sie den genauen Interpreter und seine Kompilierungseinstellungen, bevor Sie etwas testen. /usr/bin/perl kann sich von einer Perl-Installation unter /opt unterscheiden, und ein Wrapper kann PERL5LIB, Locale, Zeitzone oder aktuelles Verzeichnis verändern. Diese Unterschiede können Modulauflösung, Datumsverarbeitung, Sortierung und Textbehandlung verändern.

Führen Sie die folgenden Befehle als Produktionsbenutzer im Arbeitsverzeichnis der Produktion aus. Entfernen Sie Geheimnisse aus der gespeicherten Ausgabe:

command -v perl
perl -v
perl -V
perl -e 'print join("\n", @INC), "\n"'
env | grep '^PERL\|^LANG\|^LC_\|^TZ'

perl -V meldet, wie der Interpreter gebaut wurde, und zeigt Konfigurationswerte, die Portabilitätsfehler erklären. Die Ausgabe von @INC zeigt in der tatsächlichen Reihenfolge, wo Perl nach Modulen sucht. Speichern Sie beides mit der Bestandsaufnahme. Eine Abhängigkeit in einem privaten Anwendungsverzeichnis übersehen Sie leicht, wenn Sie nur die Paketliste des Betriebssystems prüfen.

Kompilierungsprüfungen sind nützlich, aber Sie müssen ihr Ergebnis richtig deuten:

perl -c /opt/legacy-perl/bin/post.pl

Ein Ergebnis wie syntax OK beweist, dass die Kompilierung in dieser Umgebung abgeschlossen wurde. Es beweist nicht, dass ein dynamisch geladenes Modul in einem seltenen Zweig vorhanden ist, eine Datenbankanmeldung funktioniert oder das Skript korrekte Ausgaben erzeugt. Kompilieren Sie jeden bestätigten Einstiegspunkt mit demselben Benutzer, derselben Umgebung, denselben Argumenten und demselben Arbeitsverzeichnis wie in der Produktion. Beginnen Sie nie damit, im gesamten Baum use strict hinzuzufügen oder Warnungen zu ändern. Das sind gute Praktiken für gepflegten Code, aber sie verändern die Diagnoseoberfläche, bevor Sie das Ausgangsverhalten erfasst haben.

Das Verpacken der alten Laufzeit in einen Container kann die Reproduktion erleichtern, aber ein Container ist keine archäologische Wahrheitsmaschine. Native Bibliotheken, Systembefehle, Zertifikate, DNS, Dateisystemrechte, Locale-Daten und Scheduler-Verhalten liegen weiterhin außerhalb der Perl-Abhängigkeitsliste. Erfassen Sie diese Kanten, statt anzunehmen, das Image habe sie festgehalten.

Beobachten Sie sicher, bevor Sie instrumentieren

Die Laufzeitbeobachtung sollte außerhalb des Prozesses beginnen, weil Änderungen an einem alten Skript Timing, Umgebung und Fehlerbehandlung beeinflussen können. Erfassen Sie zuerst Zeitstempel des Schedulers, Prozessdauer, geöffnete Dateien, Kindprozesse, Netzwerkziele, Exitstatus und Änderungen am Dateisystem. Sammeln Sie diese Fakten möglichst in einer kopierten Umgebung. Verwenden Sie in der Produktion nur vom Betrieb zugelassene, lesende Einrichtungen und begrenzen Sie das Beobachtungsfenster.

Das Verfolgen von Systemaufrufen hilft, wenn der Quellcode Pfade hinter Variablen oder Konfiguration verbirgt. Eine Spur kann zeigen, welche Moduldatei geöffnet wurde, welches Programm ein Skript startete und welche Konfigurationsdatei es vor einem Rückfall versuchte. Sie erfasst aber auch viele vertrauliche Daten und kann einen ausgelasteten Prozess bremsen. Filtern Sie nach Datei- und Prozessoperationen, legen Sie die Spur geschützt ab und lassen Sie den Befehl von einem Operator genehmigen. Hängen Sie sich nicht beiläufig an einen Zahlungs- oder Abrechnungsjob, nur weil die Beobachtung lesend wirkt. Auch Beobachtung hat betriebliche Kosten.

Vergleichen Sie den Prozess vor und während der Sonde. Erfassen Sie Beginn, Ende, CPU- und Speicherverbrauch, Exitstatus, Anzahl von Zeilen oder Dateien und das übliche Fehlersignal. Wenn der instrumentierte Lauf deutlich länger dauert oder die Reihenfolge verändert, verwerfen Sie ihn als Verhaltensreferenz und suchen Sie die Ursache. Eine Sonde, die das System beeinflusst, kann Abhängigkeiten zeigen, darf aber keine Parität definieren.

Protokollierung in der Anwendung kommt später. Schalten Sie sie über eine Umgebungsvariable ein, die standardmäßig deaktiviert ist, und schreiben Sie Ereignisse an fachlichen Grenzen statt bei jedem Unterprogrammaufruf. Brauchbare Ereignisse nennen den gewählten Modus, die Eingabekennung, das Regelergebnis, den Abhängigkeitspfad, die externe Aktion und den Endstatus. Protokollieren Sie nicht einfach Rohdatensätze, weil im alten Code eine Datenklassifizierung fehlt. Schwärzen Sie Werte vor der Serialisierung, damit vertrauliche Daten nie das Protokollziel erreichen.

Ein Wrapper ist oft sicherer als Änderungen am Skript. Er kann Arbeitsverzeichnis, bereinigte Umgebung, Befehlsargumente, Start- und Endzeit, Exitstatus sowie Hashes festgelegter Ausgaben erfassen. Lassen Sie die Reihenfolge der Argumente unverändert und verwenden Sie exec, wenn Prozess- und Signalverhalten erhalten bleiben sollen. Testen Sie die Signalweitergabe, denn Scheduler können ein Zeitfenster mit Abbruchsignalen durchsetzen. Ein Wrapper, der das Signal verschluckt, ändert den Produktionsvertrag.

Lassen Sie vorübergehende Ablaufverfolgung nicht ohne Verantwortlichen und Enddatum liegen. Diagnose-Hooks werden leicht dauerhaft, besonders wenn nur sie einen brauchbaren Fehlerdatensatz liefern. Soll ein Hook bleiben, behandeln Sie ihn als gepflegte Beobachtbarkeit: dokumentieren Sie Schema, Rotation, Zugriffsschutz, Schwärzung und Fehlerverhalten. Legen Sie fest, was bei vollem oder unerreichbarem Protokollziel geschieht. Ein alter Batch darf nicht aufhören, Rechnungen zu buchen, weil ein neues Diagnoselaufwerk voll ist.

Das Beobachtungsergebnis muss konkrete Zeilen im Register ändern. Ersetzen Sie einen angenommenen Modulpfad durch den beobachteten, ergänzen Sie einen neuen Kindprozess oder ändern Sie einen konfigurierten Einstiegspunkt in beobachtet. Bewahren Sie die Rohspur getrennt und mit strengeren Zugriffsrechten auf und dokumentieren Sie ihre Erhebung. So bleibt das Arbeitsregister nützlich, ohne zum Speicher für Kundendaten oder Geheimnisse zu werden.

Die CPAN-Rekonstruktion ist Beweisarbeit

Ein mit use benanntes Modul ist nicht automatisch eine CPAN-Abhängigkeit. Es kann mit der betreffenden Perl-Version ausgeliefert werden, aus einem Betriebssystempaket stammen, im Repository liegen oder eine lokal gepatchte Kopie mit dem Namen eines öffentlichen Moduls sein. Umgekehrt kann ein Skript ein Modul dynamisch laden, ohne dass eine sichtbare use-Anweisung vorkommt. Bauen Sie den Abhängigkeitssatz von der Laufzeit aus auf.

Erfassen Sie für jeden bestätigten Einstiegspunkt die Pfade geladener Module in einer sicheren Testumgebung:

perl -MData::Dumper -e 'END { print Dumper(\%INC) } do shift' /opt/legacy-perl/bin/post.pl

Diese einfache Sonde ist nicht sicher für ein Skript, das beim Laden sofort Arbeit ausführt. Verwenden Sie sie nur in einer kopierten Umgebung mit blockierten externen Schreibzugriffen oder fügen Sie einem Testzweig vorübergehend einen Diagnose-Hook hinzu. %INC ordnet geladene Modulnamen den von Perl gewählten Dateien zu und macht private Kopien sowie Überraschungen durch die Pfadreihenfolge sichtbar. Testen Sie mehr als den Erfolgsweg, denn bedingte Ladevorgänge erscheinen nur, wenn ihr Zweig läuft.

Vergleichen Sie vier Quellen: im Code gefundene Importe, %INC aus repräsentativen Läufen, Dateien in lokalen Bibliotheksverzeichnissen und installierte Distributionen, die der ursprüngliche Host meldet. perldoc perllocal kann Aufzeichnungen über Module enthalten, die mit CPAN-Werkzeugen installiert wurden, doch Systempakete und manuelle Kopien können sie unvollständig machen. Die Paketdatenbank des Betriebssystems liefert ein weiteres Teilstück. Keine dieser Quellen darf allein als maßgeblich gelten.

Schreiben Sie die rekonstruierten direkten Abhängigkeiten und Versionsgrenzen in cpanfile. Fixieren Sie, was die Anwendung nachweislich braucht, nicht jedes transitive Modul auf einem alten Server. Verwenden Sie dann Carton oder ein anderes kontrolliertes Installationswerkzeug, um die Abhängigkeiten aufzulösen und in ein isoliertes Verzeichnis zu installieren. Bewahren Sie die Ausgabe des Resolvers und Protokolle fehlgeschlagener Builds als Projektbelege auf.

requires 'DBI', '1.643';
requires 'DateTime', '1.54';
requires 'Text::CSV_XS', '1.49';

Diese Versionen sind Beispiele, keine Empfehlungen. Ihre Bedingungen müssen vom funktionierenden Host, den Anforderungen im Quellcode und Verhaltenstests stammen. Wenn keine Version angegeben war, halten Sie zuerst die installierte Version fest, die das Ausgangsverhalten erzeugt hat. Lockern Sie die Bedingung erst, wenn Tests zeigen, dass eine andere Version das Verhalten erhält.

Wenn sich ein altes Release nicht mehr installieren lässt, bestimmen Sie den genauen Fehler. Ein fehlender Compiler, eine nicht verfügbare C-Bibliothek, eine entfernte Distribution, ein fehlschlagender Test und Code, der mit einem neuen Perl nicht kompatibel ist, brauchen unterschiedliche Lösungen. Lösen Sie nicht alle fünf Probleme, indem Sie das alte site_perl-Verzeichnis kopieren. Diese Kopie kann ein Binärmodul bewahren, das für die falsche ABI kompiliert wurde, und einen Fehler hinterlassen, der erst später unter Last auftritt. Archivieren Sie ursprüngliche Distributionen und Patches, soweit die Lizenzen es erlauben, aber machen Sie den neuen Build aus deklarierten Eingaben reproduzierbar.

Reguläre Ausdrücke sind ausführbare Regeln

Der gefährliche reguläre Ausdruck ist selten der längste. Es ist der Ausdruck, dessen Treffer über Preis, Kontoklasse, Routingziel, Ablehnungsgrund oder Compliance-Markierung entscheidet. Behandeln Sie solche Ausdrücke als Geschäftsregeln, auch wenn sie in einer Ersetzung oder einem einzeiligen grep stehen. Formatierungs-Regex und Regel-Regex brauchen eine unterschiedliche Prüfung.

Finden Sie Kandidaten mit der Codesuche und ordnen Sie sie dann nach Auswirkung ein. Die Perl-Syntax macht eine perfekte statische Extraktion unrealistisch. Untersuchen Sie daher die umgebenden Zweige und Ausgaben, statt Metazeichen zu zählen. Achten Sie besonders auf Ersetzungen, Capture-Variablen wie $1, Alternativen mit Geschäftsvokabular und Muster, die aus Konfiguration aufgebaut werden.

Das Handbuch perlre erklärt, dass Perl zuerst den am weitesten links liegenden Treffer wählt und Quantifizierer standardmäßig gierig sind. Diese Tatsachen klingen elementar, werden aber zu Geschäftsverhalten, wenn Alternativen überlappen oder Captures in spätere Berechnungen eingehen. Eine spätere Bereinigung, die Alternativen neu ordnet oder einen Anker ergänzt, kann ändern, welche Kundendatensätze qualifiziert werden. Auch Änderungen an Unicode und Locale können Zeichenklassen und Groß-Kleinschreibung verändern.

Machen Sie aus jedem folgenreichen Ausdruck vor dem Refactoring eine benannte Tabelle mit Beispielen:

my @cases = (
    ['ACCT-001-EU',  'eu',       1],
    ['ACCT-001-US',  'domestic', 1],
    ['acct-001-eu',  undef,      0],
    ['ACCT-001-EU ', undef,      0],
);

for my $case (@cases) {
    my ($input, $class, $accepted) = @$case;
    my ($got) = $input =~ /\AACCT-\d{3}-(EU|US)\z/;
    my $ok = defined $got ? 1 : 0;
    die "acceptance changed for <$input>" if $ok != $accepted;
}

Die Beispielwerte sind erfunden, um die Form eines Charakterisierungstests zu zeigen. Echte Fälle sollten aus anonymisierten Produktionsdaten, abgelehnten Datensätzen, Beispielen von Bedienern und Grenzfällen stammen. Bewahren Sie führende Leerzeichen, Codierung, Zeilenenden, leere Felder und fehlerhafte Eingaben. Wenn Sie Fixtures zu früh normalisieren, löschen Sie das Verhalten, das Sie entdecken müssen.

Übertragen Sie einen dichten regulären Ausdruck nicht direkt in einen ebenso dichten Ausdruck der Zielsprache. Benennen Sie die Regel zuerst in Fachbegriffen, behalten Sie das ursprüngliche Muster als Orakel für Fixtures und schreiben Sie Tests für akzeptierte Werte, abgelehnte Werte und extrahierte Felder. Manche Ausdrücke sollten zu gewöhnlichem Parsing-Code oder zu einer Tabelle werden, weil die Regel von Menschen geprüft werden muss, die keine Regex lesen.

Erfassen Sie Verhalten an der Systemgrenze

Unit-Tests, die nachträglich an alte Interna gesetzt werden, schreiben oft Implementierungszufälle fest und übersehen dabei den Vertrag, auf den andere Systeme angewiesen sind. Erfassen Sie zuerst das Verhalten an den Grenzen: Eingabedateien, Befehlsargumente, Datenbanklesevorgänge, ausgegebene Zeilen, Exitcodes, Standardausgabe, Standardfehler, Nachrichten und Zustandsänderungen. So können Sie später die interne Architektur ändern.

Wählen Sie einen repräsentativen Korpus aus aufgezeichnetem Produktionsverkehr oder sicher kopierten Eingaben. Entfernen oder tokenisieren Sie vertrauliche Werte, erhalten Sie aber Längen, Zeichenklassen, Trennzeichen und Beziehungen, die das Parsing beeinflussen. Speichern Sie für jeden Lauf den Fingerabdruck des Interpreters, den Dependency-Lock, die Umgebung, den Eingabe-Hash, die Ausgabe, den Exitstatus und äußerlich sichtbare Schreibvorgänge. Fixieren Sie Zeit und Zufallsquellen, wenn das Programm es zulässt. Wenn nicht, vergleichen Sie stabile Felder und beschreiben Sie jedes ignorierte Feld ausdrücklich.

Ein kleines Shell-Testgerüst kann mehr aufdecken als eine Woche spekulativen Lesens:

case_dir=/tmp/perl-parity-case-01
mkdir -p "$case_dir"
cp fixtures/invoice.dat "$case_dir/input.dat"
cd "$case_dir" || exit 1
TZ=UTC LC_ALL=C /opt/oldperl/bin/perl /opt/app/run.pl input.dat >stdout.txt 2>stderr.txt
printf '%s\n' "$?" >exit-status.txt
find . -type f -print | sort >files.txt

Führen Sie dieses Gerüst in einer isolierten Umgebung aus, denn das Skript kann E-Mails senden, eine Datenbank ändern oder ein anderes Programm aufrufen. Das Umleiten der Standardausgabe schließt Nebenwirkungen nicht ein. Ersetzen Sie externe Endpunkte nach Möglichkeit durch Recorder oder stellen Sie zwischen Fällen einen Datenbank-Snapshot wieder her.

Vergleichen Sie strukturierte Daten strukturell. Sortieren Sie nur, wenn die Schnittstelle besagt, dass die Reihenfolge egal ist. Normalisieren Sie Zeitstempel nur, wenn Verbraucher sie ignorieren. Eine pauschale Bereinigung von Leerzeichen kann Schäden an Datensätzen mit fester Breite verbergen. Eine pauschale JSON-Sortierung kann eine geänderte Array-Reihenfolge verdecken. Jeder Normalisierer ist eine Aussage über die Schnittstelle und muss wie Code geprüft werden.

Verantwortlichkeit hält die Bestandsaufnahme am Leben

Eine Bestandsaufnahme ohne Verantwortliche wird selbst zum verlassenen Artefakt. Ordnen Sie jedem aktiven Einstiegspunkt einen technischen und einen fachlichen Verantwortlichen zu. Der technische Verantwortliche kann erklären, wie der Ablauf startet und wiederhergestellt wird. Der fachliche Verantwortliche kann den unterstützten Zweck benennen und Änderungen daran genehmigen. Wenn niemand die fachliche Verantwortung übernimmt, eskalieren Sie diese Tatsache vor der Stilllegung.

Legen Sie das Register zusammen mit der Modernisierungsarbeit in die Versionsverwaltung. Eine brauchbare Zeile enthält Belegstatus, letzte bestätigte Ausführung, Zeitplan, Laufzeitidentität, Eingaben, Ausgaben, Verbraucher, Abhängigkeitsmanifest, Datensensibilität, Fehlersignal, Neustartverfahren und Entscheidung. Verzichten Sie in der Zeile auf Links zu kurzlebigen Dashboards. Speichern Sie dauerhafte Kennungen, nach denen der Betrieb suchen kann.

Legen Sie vier Entscheidungen fest und behandeln Sie sie nicht als Stufen einer einzigen Pipeline:

1. Legen Sie Code still, wenn überzeugende Belege für Nichtnutzung und eine umkehrbare Quarantänezeit vorliegen.
2. Hegen Sie aktiven Code ein, dessen Verhalten zählt, dessen Änderungsrisiko aber derzeit höher als seine Wartungskosten ist.
3. Reparieren Sie Code, der mit reproduzierbarer Laufzeit, Tests und Verantwortlichem in Perl bleiben kann.
4. Schreiben Sie Code neu, dessen geschäftliche Aufgabe nötig bleibt und dessen Laufzeit-, Architektur- oder Personalrisiko einen Ersatz rechtfertigt.

Ein winziges Skript kann einen Neubau verdienen, weil es die Abrechnung sperrt oder freigibt. Ein großes Berichtsprogramm kann eingehegt bleiben, weil es stabil, isoliert und leicht zu betreiben ist. Die Zahl der Zeilen ist ein schlechter Ersatzwert für Geschäftsrisiko. Bewerten Sie Folgen, Änderungshäufigkeit, Wiederherstellbarkeit, Zustand der Abhängigkeiten und Qualität der beobachteten Verhaltensdaten.

Machen Sie Unbekanntes sichtbar

Fügen Sie eine ausdrückliche Spalte für Unbekanntes hinzu, statt jede Zeile in einen scheinbar sicheren Zustand zu zwingen. Typische Einträge sind ein ungeprüfter Datenbankalias, ein Ausgabeverzeichnis ohne benannten Verbraucher, ein Kennwort aus einem unbekannten Wrapper oder ein Modul, das nur auf einem Host liegt. Weisen Sie jeder offenen Frage einen Verantwortlichen und eine nächste Beobachtung zu. Gibt es keine geplante Beobachtung, wurde die offene Frage stillschweigend zum akzeptierten Risiko.

Das Register sollte außerdem zwischen einer Skriptinstanz und einer Quelldatei unterscheiden. Dieselbe Datei kann unter zwei Konten mit anderer Konfiguration, anderen Argumenten und Rechten laufen. Das sind zwei Produktionsverhalten und sie können verschiedene Entscheidungen brauchen. Hashen Sie die bereitgestellte Datei, damit Sie erkennen, ob scheinbar gleiche Pfade unterschiedliche Kopien enthalten. Erfassen Sie Symlink-Ziele, weil ein Release-Umschalter denselben Pfad heute auf anderen Code zeigen lassen kann als gestern.

Fehler legen Abhängigkeiten offen, die erfolgreiche Läufe verbergen. Prüfen Sie Scheduler-Mails, Dead-Letter-Verzeichnisse, teilweise erzeugte Ausgaben, Wiederholungsskripte und Tickets des Betriebs. Ein Wiederherstellungsbefehl in einem Runbook kann die einzige eingehende Kante zu einem Reparaturskript sein. Löscht das Team dieses Skript, weil der normale Produktionslauf es nie aufruft, wird der nächste fehlerhafte Batch zum Entdeckungswerkzeug. Kennzeichnen Sie reine Wiederherstellungs-Einstiegspunkte als aktiv und testen Sie sie an einem umkehrbaren Fehlerfall.

Auch eine Stilllegung braucht einen Ausgabevertrag. Ermitteln Sie bei einem Bericht, wer ihn erhält und was bei seinem Ausbleiben geschieht. Finden Sie bei einem Übertragungsjob die Bestätigung oder den Abstimmungsdatensatz. Bestimmen Sie bei einem Bereinigungsjob, welches Speicher-, Laufzeit- oder Korrektheitssymptom zurückkehrt, wenn er stoppt. Ein Skript ohne sichtbaren Aufrufer kann weiterhin ein negatives Ergebnis verhindern, etwa doppelte Zeilen oder nicht gelöschte temporäre Daten. Suchen Sie nach dem Zustand, den es unterdrückt.

Nutzen Sie das Register bei Störungen. Wenn jemand einen neuen Aufruf, einen aktualisierten Interpreter oder einen unbekannten Verbraucher entdeckt, ändern Sie den Datensatz im selben Commit wie die operative Korrektur. Nach mehreren Störungszyklen wird die Bestandsaufnahme genauer, weil sie Belege aus realen Belastungen aufnimmt. Eine einmal an die Leitung verschickte Tabelle veraltet, weil die Menschen mit neuen Erkenntnissen sie nicht dort pflegen können, wo sie arbeiten.

Wählen Sie eine fachliche Naht, keine Dateigrenze

Ein Neubau Datei für Datei bewahrt die Zufälle der alten Struktur. Wählen Sie eine Naht um eine beobachtbare Fähigkeit: einen Feed einlesen, Datensätze klassifizieren, eine Gebühr berechnen, einen Bericht erstellen oder einen Batch buchen. Definieren Sie die Grenze mit Eingaben, Ausgaben, Fehlerverhalten und Zustandsänderungen und lassen Sie dann alte und neue Implementierung dieselben Fälle ausführen.

Strangler-Einführungen sind beliebt, weil sie die Größe der Umstellung verringern. Sie sind aber falsch, wenn die vorgeschlagene Naht Transaktionen oder veränderlichen Zustand teilt, der sich nicht sicher trennen lässt. Zwei schreibende Systeme gegen ein kaum verstandenes Schema schaffen mehr Mehrdeutigkeit als der Ersatz eines zusammenhängenden Batchs. Bauen Sie in diesem Fall einen mitlaufenden Leser, vergleichen Sie die Ausgaben und stellen Sie die gesamte Schreibgrenze um, sobald die Parität belastbar ist. Die Naht sollte der Verantwortung für Auswirkungen folgen, nicht den Funktionsnamen in Perl.

Übertragen Sie Perl-Idiome nicht wortgetreu in eine neue Sprache. Implizite globale Variablen, kontextabhängige Rückgabewerte, Autovivifikation, Wahrheitswerte und Regex-Nebenwirkungen können das alte Programm geprägt haben, aber die neue Architektur sollte Zustand und Fehler ausdrücklich machen. Bewahren Sie äußeres Verhalten, auf das Verbraucher angewiesen sind. Ersetzen Sie inneres Verhalten, das nur existiert, weil Perl es bequem machte.

CodeHero liest den gesamten gemischtsprachigen Baum, schreibt Perl in Go, Rust oder TypeScript neu und prüft das Verhalten mit einem Paritätsgerüst gegen aufgezeichneten Produktionsverkehr. Dieser Ansatz passt erst, wenn Ausführungsbelege und Grenzfälle vorhanden sind. Ein automatisierter Neubau kann keine vierteljährliche Eingabe wiederfinden, die niemand erfasst hat, und keine Entscheidung eines Bedieners, die außerhalb des Codes lebte.

Die ersten zehn Arbeitstage müssen Unsicherheit abbauen

Die ersten Arbeitstage sollten Belege liefern, kein neu geschriebenes Modul. Stoppen Sie am ersten Tag beiläufige Bereinigungen und bestimmen Sie Hosts, Repositories, Scheduler und Menschen, die Ausgaben erhalten. Bis zum dritten Tag sollten Sie bestätigte Einstiegspunkte, Laufzeitfingerabdrücke und eine Liste unbekannter Verbraucher haben. Bis zum sechsten Tag sollten repräsentative Läufe geladene Abhängigkeiten und Auswirkungen an den Grenzen zeigen. Am zehnten Tag sollte das Team jede Entscheidung mit Aufzeichnungen statt mit Selbstvertrauen begründen können.

Schützen Sie die Produktion, während Sie diese Belege sammeln. Lesen Sie Konfiguration, bevor Sie sie ändern. Erfassen Sie Befehle und Ausgaben in einem kontrollierten Protokoll. Entfernen Sie Geheimnisse. Führen Sie kopierte Skripte erst aus, nachdem Sie Mailversand, Datenbankschreibzugriffe, entfernte Aufrufe und zerstörerische Dateipfade blockiert haben. Lassen Sie jede Sonde, die einen aktiven Scheduler oder ein Produktionskonto berührt, von einem Operator prüfen.

Die unbequeme Erkenntnis kann lauten, dass niemand den Interpreter neu bauen kann, mehrere CPAN-Releases aus üblichen Installationswegen verschwunden sind und die einzige Spezifikation aus einem regulären Ausdruck plus den Dateien des letzten Jahres besteht. Auch das ist Fortschritt. Sie wissen jetzt, wo das Risiko liegt. Bewahren Sie die funktionierende Laufzeit, sammeln Sie repräsentative Eingaben, benennen Sie den fachlichen Verantwortlichen und machen Sie das Verhalten in Tests ausführbar.

Belohnen Sie nicht den ersten Entwickler, der den alten Code modern aussehen lässt. Belohnen Sie denjenigen, der beweist, was der Betrieb weiterhin von ihm verlangt. Sobald dieser Beweis vorliegt, werden Löschen und Neuschreiben zu technischen Entscheidungen statt zu Folklore.