Michael Korte – Senior Full-Stack Developer Freelancer aus Dortmund

Teil 13 – Warum Logging der erste echte Schritt ist

Bevor neue Mechanismen eingeführt werden, stellt sich eine grundlegende Frage: Woher wissen wir eigentlich, was das System gerade tut?

In vielen Projekten wird diese Frage spät gestellt – oft erst dann, wenn etwas nicht mehr funktioniert. v0.2 dreht diese Reihenfolge bewusst um.

Warum Debug-Ausgaben nicht reichen

Klassisches Debugging fühlt sich vertraut an:

• var_dump()
• echo
• die()
• temporäre HTML-Ausgaben

All das funktioniert – aber nur solange Output egal ist. In einem System, das HTML als Produkt versteht, wird genau das zum Problem.

Was Logging in v0.2 bedeutet

Logging ist in v0.2 kein Nebenfeature, sondern Core-nahe Infrastruktur.

• zentral initialisiert
• konsequent ohne HTML-Ausgabe
• abschaltbar
• maschinenlesbar

Entscheidend ist nicht die Menge der Logs, sondern ihre Position im Lifecycle.

Ein erster Blick in den Ablauf

Bereits beim Start der Anwendung wird sichtbar, dass das System arbeitet:

// App::run()
$logger->log(
    LogLevel::INFO,
    'core',
    App::class,
    'App run start'
);
    

Dieser Eintrag erzeugt keinen Output, beeinflusst kein Rendering – aber er markiert zuverlässig den Einstiegspunkt.

Beobachten statt kontrollieren

Ein wichtiges Detail: Logging entscheidet nichts.

• keine Weiterleitungen
• keine Fallbacks
• keine Fehlerbehandlung

Es beschreibt lediglich, was passiert ist.

Logging als Grundlage für spätere Werkzeuge

In v0.2 bleibt Logging bewusst einfach. Trotzdem legt es bereits den Grundstein für:

• Admin-Oberflächen
• Health-Checks
• Request-Analysen
• Fehler-Auswertungen

Nicht durch neue Features, sondern durch verlässliche Informationen.