Code-Review in PHP: Was man prüfen sollte und wie man Feedback in der Praxis gibt

Einleitung: Warum Code-Review nicht Kontrolle, sondern Wachstum bedeutet

Code-Review in PHP ist kein archaisches Kontrollverfahren eines Vorgesetzten gegenüber einem Untergebenen. Es ist ein professioneller Dialog zwischen Entwicklern, der darauf abzielt, die Codequalität zu verbessern, Wissen im Team zu verbreiten und Fehler frühzeitig zu verhindern. Die Praxis zeigt jedoch, dass viele PHP-Entwickler (besonders am Anfang) entweder Angst vor dem Review haben oder es zu einer leeren Formalität verkommen lassen.

In diesem Artikel gehen wir darauf ein, worauf man bei einem Code-Review von PHP-Code konkret achten sollte, wie man Anmerkungen formuliert, um Kollegen nicht zu verletzen, und wie man selbst den größtmöglichen Nutzen aus diesem Prozess zieht. Das Material basiert auf praktischer Erfahrung mit Projekten unter PHP 7.4+ und Frameworks wie Laravel und Symfony.

1. Was im PHP-Code prüfen: Eine praktische Checkliste

Eine universelle Liste gibt es nicht, aber für PHP-Projekte lassen sich 5 Schlüsselbereiche identifizieren, die man auf jeden Fall durch die Review-Brille betrachten sollte.

1.1. Sicherheit (Security)

PHP ist eine Sprache, in der man leicht Schwachstellen einbauen kann. Als Erstes prüfen wir:

\n
• SQL-Injection: Werden vorbereitete Anweisungen (PDO / prepared statements) anstelle von String-Konkatenation verwendet?
\n
• XSS (Cross-Site Scripting): Wird die Ausgabe durch htmlspecialchars() oder Template-Engines (Blade, Twig) maskiert?
\n
• CSRF-Schutz: Sind Token in Formularen vorhanden, die den Zustand ändern?
\n
• Eingabevalidierung: Werden Typ und Länge der Daten serverseitig überprüft?
\n

// Schlecht: Konkatenation in SQL\n$query = "SELECT * FROM users WHERE id = " . $_GET['id'];\n\n// Gut: Vorbereitete PDO-Anweisung\n$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');\n$stmt->execute(['id' => $_GET['id']]);\n

1.2. Architektur und SOLID

Auch wenn das Projekt kein Enterprise-Projekt ist, sollten grundlegende Prinzipien eingehalten werden:

\n
• Einzelverantwortung: Macht die Klasse/Methode nicht zu viel?
\n
• Abhängigkeitsinversion: Verwendet der Code Schnittstellen anstelle konkreter Klassen?
\n
• Keine Gott-Objekte: Gibt es keine Klassen mit über 1000 Zeilen?
\n

1.3. Stil und PSR-Standards

Für PHP ist das entscheidend. Wir prüfen die Einhaltung von PSR-12 (Codierungsstil):

\n
• Einrückung: 4 Leerzeichen, keine Tabulatoren.
\n
• Geschweifte Klammern bei Klassen und Methoden in einer neuen Zeile.
\n
• Korrekte Benennung: camelCase für Methoden, snake_case für Variablen (sofern im Projekt nicht anders festgelegt).
\n

1.4. Leistung (Performance)

In PHP kann man leicht langsamen Code schreiben. Wir suchen nach:

\n
• Abfragen in Schleifen (N+1-Problem) — stattdessen Eager Loading im ORM verwenden.
\n
• Ignorieren von Caching: wiederholte Berechnungen derselben Daten.
\n
• Ineffiziente Funktionen: z. B. in_array() bei großen Arrays besser durch isset($hash[$key]) ersetzen.
\n

// Schlecht: Abfrage in der Schleife\nforeach ($users as $user) {\n    $posts = DB::table('posts')->where('user_id', $user->id)->get();\n}\n\n// Gut: Eine Abfrage mit Eager Loading\n$users = User::with('posts')->get();\n

1.5. Fehlerbehandlung und Typisierung

\n
• Ist strict_types am Anfang der Datei vorhanden?
\n
• Werden Typen für Argumente und Rückgabewerte verwendet?
\n
• Werden Ausnahmen behandelt und nicht mit einem bloßen try-catch unterdrückt?
\n

2. Wie man Feedback gibt: Von "Das ist schlecht" zu "Lass uns verbessern"

Die schwierigste Fähigkeit beim Code-Review ist nicht, einen Fehler zu finden, sondern ihn richtig zu präsentieren. Schlechtes Feedback tötet die Motivation. Gutes Feedback lehrt und bringt das Team näher zusammen.

2.1. Die "Sandwich"-Regel

Die Fül