PHP-Code-Review: 10 Fehler, die Senioren nerven

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Einleitung: Warum wird Ihr PHP-Code zur Überarbeitung zurückgeschickt?

\n

Sie haben einen Pull Request eingereicht, voller Zuversicht, perfekten Code geschrieben zu haben. Eine Stunde vergeht, und Sie sehen 15 Kommentare von einem Senior-Entwickler. Kommt Ihnen bekannt vor? Code-Review in PHP ist nicht nur eine Formalität, sondern eine echte Prüfung der Reife. Senioren betrachten Code nicht als eine Reihe von Anweisungen, sondern als ein System, das leben und sich weiterentwickeln wird.

\n

In diesem Artikel analysieren wir die häufigsten Anmerkungen, die Sie im Review erhalten. Wir werden Ihnen nicht die Syntax beibringen – Sie wissen bereits, wie man eine Variable deklariert. Wir sprechen über Code-Kultur, Architektur und Fallstricke, die funktionierenden Code in einen Albtraum für die Wartung verwandeln. Machen Sie sich bereit: Es wird schmerzhaft, aber nützlich sein.

\n\n

1. Magische Zahlen und Zeichenketten: "Was bedeutet 42?"

\n

Der häufigste und nervigste Fehler. Ein Senior sieht im Code if ($status == 3) und gibt sofort einen Minuspunkt. Die Zahl 3 ist eine magische Konstante. In einem Monat werden Sie sich selbst nicht mehr daran erinnern, was sie bedeutet. Und ein neuer Entwickler wird raten: Ist das der Status "Veröffentlicht", "Im Entwurf" oder "Gelöscht"?

\n\n

Schlecht:

\n
if ($order->getStatus() == 3) {\n    $order->sendNotification();\n}
\n\n

Gut:

\n
class OrderStatus {\n    const PENDING = 1;\n    const CONFIRMED = 2;\n    const SHIPPED = 3;\n    const DELIVERED = 4;\n}\n\nif ($order->getStatus() === OrderStatus::SHIPPED) {\n    $order->sendNotification();\n}
\n

Die Verwendung benannter Konstanten macht den Code selbstdokumentierend. Sie schreiben nicht nur Code – Sie erzählen eine Geschichte. Dies ist eine der wichtigsten PHP-Best-Practices, die Junioren oft ignorieren.

\n\n

2. God-Objekte und Monster mit 500 Zeilen

\n

"Diese Klasse macht alles!" – ein Satz, der einem Senior einen Schauer über den Rücken jagt. Wenn eine Klasse sowohl für das Senden von E-Mails, als auch für die PDF-Generierung und die Datenbankarbeit verantwortlich ist, verstößt dies gegen das Prinzip der einzigen Verantwortung (SRP). Eine solche Klasse ist nicht testbar, schwer zu ändern und wird beim geringsten Refactoring garantiert kaputtgehen.

\n\n

Anzeichen eines God-Objekts:

\n
    \n
  • Die Klasse enthält mehr als 200-300 Zeilen
  • \n
  • Eine Methode hat mehr als 20-30 Zeilen
  • \n
  • Der Klassenname endet auf "Manager" oder "Helper"
  • \n
  • Methoden akzeptieren 5+ Parameter
  • \n
\n

Die Lösung ist einfach: Aufteilen! Lagern Sie die Logik in Services, Repositories, Handler aus. PHP-Refaktorisierung beginnt im Kleinen – erstellen Sie eine Klasse, die nur eine Sache tut, aber diese gut macht.

\n\n

3. "Nackte" Arbeit mit SQL über PDO

\n

Ja, PDO schützt vor Injection, wenn Sie Prepared Statements verwenden. Aber ein Senior möchte im Controller kein rohes SQL sehen, sondern eine Abstraktion. ORMs wie Eloquent oder Doctrine sind der Standard. Wenn das Projekt klein ist, verwenden Sie zumindest einen Query Builder.

\n\n

Antipattern:

\n
$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');\n$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?');\n$stmt->execute([$email]);\n$user = $stmt->fetch();
\n\n

Richtiger Ansatz:

\n
class UserRepository {\n    public function findByEmail(string $email): ?User {\n        return User::where('email', $email)->first();\n    }\n}
\n

Die Arbeit über ein Repository ermöglicht es, die Datenquelle einfach zu wechseln (z. B. auf Redis-Cache umzusteigen), ohne das gesamte Projekt umschreiben zu müssen. Dies ist PHP-Codequalität, die mit Gold aufgewogen wird.

\n\n

4. Ignorieren von strict_types

\n

PHP ist eine dynamisch typisierte Sprache, aber das ist kein Grund, Code wie im Jahr 2005 zu schreiben. Die Deklaration declare(strict_types=1); am Anfang jeder Datei ist ein Zeichen von Professionalität. Ein Senior hasst es, wenn eine Funktion einen int erwartet, aber einen String "42" erhält und diesen stillschweigend konvertiert.

\n\n
declare(strict_types=1);\n\nfunction calculateTotal(int $price, int $quantity): int {\n    return $price * $quantity;\n}\n\n// Dies löst einen TypeError aus, keine stille Konvertierung\necho calculateTotal('100', 2); /                

Blogs

Buchempfehlungen