Laravel-Code-Review-Checkliste für 2026

Sie haben einen Anbieter damit beauftragt, Ihre Laravel-App zu entwickeln. Die Demo läuft, die Screens laden, und die Rechnung ist bereits unterwegs. Was jedoch unter der Haube steckt, ist eine eigene Frage – eine, die die meisten Teams erst stellen, wenn etwas kaputt geht.

Diese Vertrauenslücke ist der Grund, warum wir diesen Leitfaden zusammengestellt haben. Die folgende Liste ist dieselbe, die unsere Reviewer bei der Prüfung von Laravel-Codebasen verwenden, und sie spiegelt das Framework hinter jedem Laravel-Code-Review wider, das wir für Kunden durchführen. Viele Teams erben eine Laravel-Codebasis, anstatt sie zu hinterfragen – führen Sie daher die folgenden Schritte vor dem nächsten Übergabe oder Release durch, um zu erkennen, was später am teuersten zu beheben ist.

Laravel-Codierungsstandards (PSR-12)

Code, der Konventionen ignoriert, ist schwer zu lesen, macht das Onboarding neuer Entwickler schwierig und zieht Bugs an. PSR-12 ist der PHP-FIG-Standard, dem das Laravel-Ökosystem standardmäßig folgt, und ein Review beginnt hier, weil jede spätere Prüfung auf einer lesbaren Codebasis aufbaut. Wir betrachten diese Ebene als Grundvoraussetzung, nicht als nice-to-have.

Was wir bei Formatierung und Benennung prüfen

Drei Muster, die wir zuerst markieren, wenn wir eine neue Codebasis öffnen:

Gemischte Einrückung, Zeilen länger als 120 Zeichen, keine Type-Hints irgendwo.
Modelle in Pluralform benannt (Users statt User), Controller ohne das Controller-Suffix.
snake_case-Spalten neben camelCase-Spalten in derselben Migration.

Ein sauberer Reviewer-Durchgang erwartet 4-Leerzeichen-Einrückung, PascalCase-Modelle, camelCase-Methoden, snake_case-Spalten, Plural-Tabellennamen und Type-Hints bei jedem Parameter und Rückgabewert. PHPDoc-Blöcke sollten das Warum bei öffentlichen Methoden erklären.

Pint und Larastan in CI

Tools erzwingen Laravel-Codierungsstandards, sodass Reviewer sich auf die Logik konzentrieren können. Pint ist der offizielle Laravel-Formatter, und Larastan fügt Laravel-bewusste statische Analyse auf PHPStan auf. Beide sollten in Continuous Integration laufen, denn Konventionen halten nur, wenn die Pipeline Merges blockiert, die sie brechen.

Ein minimaler CI-Schritt sieht so aus:

vendor/bin/pint --test
vendor/bin/phpstan analyse --memory-limit=2G

Wenn einer der Befehle fehlschlägt, stoppt der Pull Request. Diese eine Regel verhindert den größten Teil des Style-Drifts bei Teams jeder Größe.

Sauberer Code und Architektur

Laravel macht die Auslieferung schnell, was sowohl seine Stärke als auch seine Falle ist. Viele Codebasen, die wir prüfen, haben ein funktionierendes MVP geliefert, bei dem die Logik auf Controller, Modelle und Blade-Templates verteilt ist – und der spätere Aufräumaufwand kostet mehr als der ursprüngliche Aufbau. Laravel-Clean-Code ist der Unterschied zwischen einer Codebasis, die Sie im zweiten Jahr erweitern können, und einer, die Sie neu schreiben müssen.

Schlanke Controller, Service-Klassen und Action-Klassen

Die Aufgabe eines Controllers ist HTTP, nicht mehr. Wenn wir Methoden mit mehr als 30 Zeilen sehen, wissen wir, dass Business-Logik eingedrungen ist – die Lösung ist eine Service-Klasse oder eine Single-Purpose-Action-Klasse.

Schlecht:

public function store(Request $request)
{
    $data = $request->validate([
        'email' => 'required|email',
        'plan'  => 'required|in:basic,pro',
    ]);

    $user = User::create($data);
    Mail::to($user->email)->send(new WelcomeMail($user));
    Subscription::create([
        'user_id' => $user->id,
        'plan'    => $data['plan'],
    ]);

    return redirect()->route('dashboard');
}

Besser:

public function store(RegisterRequest $request, RegisterUser $action)
{
    $action->execute($request->validated());

    return redirect()->route('dashboard');
}

Der Controller lässt sich jetzt in einem Atemzug lesen. Die Action-Klasse ist eigenständig testbar und von einem Konsolenbefehl oder einem Queue-Job aus wiederverwendbar – das ist es, was Refactorings sicher macht.

Form Requests und Policies

Inline-Validierung und Inline-Autorisierung sind zwei der häufigsten Abkürzungen, die wir entwirren. Validierungsregeln gehören in Form-Request-Klassen, und Autorisierung gehört in Policies, die gegen das Modell registriert sind. Beide Maßnahmen verkleinern Controller und platzieren die Regeln dort, wo Entwickler sie erwarten – das beschleunigt das Onboarding und reduziert Bugs, die die nächste Person einführt, die die Datei anfasst.

Wenn Sie immer wieder Controller mit 200 Zeilen gemischter Verantwortlichkeiten entdecken, liegt das Problem tiefer als ein Refactoring, und es könnte an der Zeit sein, einen Software-Architekturberater hinzuzuziehen, bevor aus dem Aufräumen ein Neuentwurf wird.

Eloquent und Datenbankabfragen

Eloquent ist zu gleichen Teilen elegant und gefährlich. Das ORM verbirgt die Kosten einer Abfrage, und ein sorgloses foreach löst im Hintergrund hunderte von Datenbankaufrufen aus. Performance-Audits beginnen oft in dieser Schicht.

N+1-Abfragen und Eager Loading

Die N+1-Abfrage ist der häufigste Laravel-Performance-Bug, den wir finden. Das Muster sieht auf dem Bildschirm harmlos aus:

$posts = Post::all();

foreach ($posts as $post) {
    echo $post->author->name; // one extra query per post
}

Die Lösung ist with():

$posts = Post::with('author')->get();

foreach ($posts as $post) {
    echo $post->author->name; // no extra queries
}

Fügen Sie Model::preventLazyLoading() in Ihrem AppServiceProvider für Nicht-Produktionsumgebungen hinzu, und Laravel wird eine Exception werfen, sobald Lazy Loading auftritt. Der Bug taucht in Ihrer Test-Suite auf, statt unter Produktionslast.

Indizes, Mass Assignment und Migrationen

Drei Datenbank-Schicht-Prüfungen, die wir bei jedem Audit durchführen:

Fremdschlüssel und häufig gefilterte Spalten haben Indizes.
Modelle deklarieren $fillable oder $guarded bewusst, sodass eine unerwartete Eingabe keine Admin-only-Felder überschreiben kann.
Migrationen haben funktionierende down()-Methoden, sodass Rollbacks keine Produktionsdaten korrumpieren.

Der dritte Punkt ist wichtiger, als die meisten Teams erkennen. Eine Migration ohne Rollback ist eine Einbahnstraße, und diese Tür öffnet sich immer zum ungünstigsten Zeitpunkt.

Laravel-Sicherheits-Best-Practices

Sicherheit ist der Bereich, in dem Anbieter-Übergaben am schmerzhaftesten scheitern. Laut dem IBM Cost of a Data Breach Report 2025 kostet ein Datenleck weltweit im Durchschnitt 4,44 Millionen USD und in den USA 10,22 Millionen USD. Ein Code-Review ist der günstigste Zeitpunkt, um die Lücken zu finden, die zu diesen Zahlen führen.

Umgebung, CSRF, XSS und Datei-Uploads

Dies sind die am häufigsten übersehenen Laravel-Sicherheits-Best-Practices in unseren Audits. Eine kurze Prüfliste:

APP_DEBUG=false und APP_ENV=production in Produktionsumgebungen.
.env aus der Versionskontrolle ausgeschlossen und gibt 403 über HTTP zurück.
CSRF-Middleware bei jeder zustandsändernden Route aktiviert.
Blade {{ }} wird für die Ausgabe verwendet, {!! !!} nur nach expliziter Bereinigung.
Datei-Uploads werden auf MIME-Typ, Größe und Erweiterung validiert und dann außerhalb des öffentlichen Verzeichnisses gespeichert.

Das OWASP Top 10 behandelt die übergeordneten Kategorien, gegen die diese Prüfungen schützen. Die Zuordnung Ihrer Audit-Ergebnisse zu OWASP-Kategorien gibt dem Bericht eine Struktur, die Ihr Sicherheitsteam kennen wird.

Authentifizierung, Rate Limiting und Abhängigkeits-Audits

Passwörter sollten mit bcrypt oder Argon2 gehasht werden, niemals mit MD5 oder SHA1. APIs sollten Laravel Sanctum oder Passport verwenden, wobei die Throttle-Middleware auf Login- und Passwort-Reset-Endpunkte angewendet wird, um Brute-Force zu stoppen. Der Befehl composer audit sollte bei jedem Build in CI ausgeführt werden, damit eine neu veröffentlichte Schwachstelle in einer Abhängigkeit nicht wochenlang unbemerkt bleibt.

Ein einziges veraltetes Paket kann jede andere Prüfung auf dieser Liste zunichte machen. Deshalb ist ein Review ohne ein Abhängigkeits-Audit unvollständig.

Laravel-Performance-Optimierung

Performance-Probleme kommen selten als einzelner Bug. Sie bauen sich über mehrere Schichten auf, und ein Review legt die Schichten frei, die still teuer sind. Laravel-Performance-Optimierung während eines Audits ist Diagnose, keine Implementierung – der Bericht sagt Ihnen, wo die Kosten liegen und warum.

Ein paar Dinge, die wir bei jedem Projekt überprüfen:

Route-, Config-, View- und Event-Caches sind in der Produktion aufgewärmt (php artisan route:cache, config:cache, view:cache, event:cache).
Schwere Arbeit (E-Mail, Exporte, Drittanbieter-API-Aufrufe, Bildverarbeitung) wird an Queues mit einem echten Treiber wie Redis übergeben, nicht synchron.
Jeder Listen-Endpunkt ist paginiert, ohne Model::all() bei einer wachsenden Tabelle.
Eine Cache-Schicht liegt vor teuren Lesevorgängen mit sinnvollen Time-to-Live-Werten.
OPcache ist auf PHP-Ebene aktiviert.
Telescope- oder Laravel-Debugbar-Befunde aus dem Staging wurden überprüft.

Ein häufiges Muster bei MVPs ist die Bereitstellung ohne all das Obige und die Entdeckung der Kosten, wenn der Traffic nach einem Launch verdoppelt. Der Trade-off ist in unserer Analyse der versteckten Kosten, die später auftauchen.

Tests und Zuverlässigkeit

Eine Laravel-App ohne Tests ist eine Laravel-App, die ein Refactoring vom Produktionsausfall entfernt ist. Die Codebasis muss keine 100%ige Abdeckung haben, um sicher zu sein, aber die kritischen Pfade absolut schon. Wir suchen nach einer Pest- oder PHPUnit-Suite, die in Continuous Integration grün läuft, Feature-Tests für jeden umsatzberührenden Flow (Authentifizierung, Zahlung, Core-CRUD), Factories für die Hauptmodelle, damit Testdaten eine Codezeile sind, dem RefreshDatabase-Trait bei jedem Test, der die Datenbank berührt, und externen APIs, die während der Suite gemockt statt aufgerufen werden.

Wenn die Suite fehlt oder rot ist, ist der richtige Ausgangspunkt Charakterisierungstests rund um das aktuelle Verhalten, gefolgt von Refactoring. Abdeckung, die um einen eingefrorenen Vertrag aufgebaut ist, ist die einzige Art, der Sie später vertrauen können – und Teams, die diesen Schritt überspringen, zahlen dafür in der Regel zweimal: erst an Vertrauen, dann in Incident-Berichten.

Abhängigkeiten und Tooling

Der Abhängigkeitsgraph ist oft der am häufigsten übersehene Teil einer Laravel-Applikation. Veraltete Frameworks und verlassene Pakete machen einen großen Teil der Schwachstellen und Inkompatibilitäten aus, die wir sehen – und der Betrieb auf unterstützten Versionen korreliert stark mit der Team-Velocity in jeder Entwicklerumfrage der letzten Jahre.

Die Checkliste hier ist kurz, aber sie beißt, wenn Sie sie überspringen. Laravel sollte auf einem unterstützten Release laufen (Laravel 12 hat Sicherheitsunterstützung bis zum 24. Februar 2027). PHP sollte auf 8.3 oder 8.4 sein, nicht früher. Die Datei composer.lock sollte committed und identisch auf Entwicklermaschinen, CI und Produktion sein. Es sollte keine Pakete geben, die von composer audit als verlassen markiert wurden. Pint, Larastan und Pest sollten bei jedem Push in CI laufen, wobei Rector hinzugefügt wird, wenn Sie automatisierte Upgrade-Refactorings über PHP- und Laravel-Versionen hinweg wünschen.

Was unsere Laravel-Code-Review-Checkliste in echten Audits aufdeckt

Zahlen erzählen die Geschichte besser als Versprechen. Im letzten Audit-Zyklus unseres Teams protokollierten unsere Reviewer 82 Sicherheitslücken in 15 Laravel- und PHP-Projekten, 27 Fälle von Copy-Paste-Programmierung und 23 Fälle von Abhängigkeitskonflikten, die schwerwiegend genug waren, um Deployments zu blockieren. Die meisten dieser Probleme steckten in Code, den das ursprüngliche Team für produktionsreif hielt.

Top 5 Laravel-Warnsignale

Die Muster wiederholen sich in Audits, und diese fünf Probleme treten am häufigsten auf:

Fette Controller mit Validierung, Business-Logik und Seiteneffekten in einer einzigen Methode.
N+1-Abfragen auf Dashboard-Endpunkten, die erst unter echter Last auftauchen.
.env durch APP_DEBUG=true bei einer öffentlich zugänglichen Staging-URL geleakt.
Kein Rate Limiting bei Login oder Passwort-Reset, was die Tür für Brute-Force offen lässt.
KI-generierter Code, der auf dem Happy Path läuft und still Form Requests, Policies und Tests überspringt.

Wenn ein MVP mit mehreren dieser Punkte geliefert wird, ist der sauberste Weg nach vorne ein strukturiertes Review, gefolgt von laufender Laravel-Wartung statt einem weiteren vollständigen Neuentwurf. Für Teams, die bereit sind, denselben Stack in ein kostenpflichtiges Produkt zu skalieren, schließen unsere Laravel-Entwicklungsdienstleistungen dort an, wo der Review-Bericht endet.

Abschließende Gedanken

Eine Laravel-Code-Review-Checkliste ist kein Ersatz für das Urteilsvermögen erfahrener Ingenieure, aber es ist der günstigste Weg, dieses Urteil wiederholbar zu machen. Das Befolgen etablierter Laravel-Best-Practices bei jedem Review, jedem Release und jeder Anbieter-Übergabe ist das, was eine App, die Sie skalieren können, von einer, die Sie neu bauen müssen, trennt. Die Arbeit amortisiert sich das erste Mal, wenn Sie einen Freitagnacht-Rollback oder eine Montagmorgen-Sicherheitsoffenlegung vermeiden.

Wenn Sie lieber ein zweites Augenpaar auf die Codebasis haben möchten, oder einfach nicht die Kapazität haben, das Audit intern durchzuführen, kontaktieren Sie uns und wir werden ein Review rund um Ihren Stack planen.

Laravel-Code-Review-Checkliste