Revue de code PHP : 10 erreurs qui agacent les seniors

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Introduction : Pourquoi votre code PHP est-il réécrit ?

\n

Vous avez soumis une Pull Request, convaincu d'avoir écrit un code parfait. Une heure passe, et vous voyez 15 commentaires d'un développeur senior. Ça vous dit quelque chose ? La revue de code en PHP n'est pas une simple formalité, mais un véritable examen de maturité. Les seniors ne voient pas le code comme un ensemble d'instructions, mais comme un système qui va vivre et évoluer.

\n

Dans cet article, nous allons décortiquer les remarques les plus courantes que vous recevez en revue. Nous n'allons pas vous apprendre la syntaxe — vous savez déjà comment déclarer une variable. Nous allons parler de culture du code, d'architecture et des pièges qui transforment un code fonctionnel en cauchemar de maintenance. Préparez-vous : ça va faire mal, mais c'est utile.

\n\n

1. Nombres et chaînes magiques : "Que signifie 42 ?"

\n

L'erreur la plus fréquente et la plus agaçante. Un senior voit dans le code if ($status == 3) et met immédiatement un moins. Le nombre 3 est une constante magique. Dans un mois, vous ne vous souviendrez plus de ce qu'il signifie. Et un nouveau développeur devra deviner : est-ce le statut "Publié", "En brouillon" ou "Supprimé" ?

\n\n

Mauvais :

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

Bon :

\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

L'utilisation de constantes nommées rend le code auto-documenté. Vous n'écrivez pas seulement du code — vous racontez une histoire. C'est l'une des principales php best practices que les juniors ignorent souvent.

\n\n

2. Objets God et monstres de 500 lignes

\n

"Cette classe fait tout !" — une phrase qui fait frémir un senior. Quand une seule classe est responsable de l'envoi d'email, de la génération de PDF et du travail avec la base de données, c'est une violation du principe de responsabilité unique (SRP). Une telle classe est impossible à tester, difficile à modifier, et elle se cassera inévitablement à la moindre refactorisation.

\n\n

Signes d'un objet God :

\n
    \n
  • La classe contient plus de 200-300 lignes
  • \n
  • Une méthode contient plus de 20-30 lignes
  • \n
  • Le nom de la classe se termine par "Manager" ou "Helper"
  • \n
  • Les méthodes acceptent 5+ paramètres
  • \n
\n

La solution est simple : divisez ! Extrayez la logique dans des services, des repositories, des handlers. Le refactoring PHP commence par de petites choses — créez une classe qui ne fait qu'une seule chose, mais qui la fait bien.

\n\n

3. Travail "brut" avec SQL via PDO

\n

Oui, PDO protège contre les injections si vous utilisez des prepared statements. Mais un senior veut voir non pas du SQL brut dans le contrôleur, mais une abstraction. Les ORM comme Eloquent ou Doctrine sont la norme. Si le projet est petit, utilisez au moins un Query Builder.

\n\n

Anti-patron :

\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

Approche correcte :

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

Travailler via un repository permet de changer facilement la source de données (par exemple, passer à un cache Redis) sans réécrire tout le projet. C'est la qualité de code PHP qui est inestimable.

\n\n

4. Ignorer strict_types

\n

PHP est un langage à typage dynamique, mais ce n'est pas une raison pour écrire du code comme en 2005. La déclaration declare(strict_types=1); au début de chaque fichier est un signe de professionnalisme. Un senior déteste quand une fonction attend un int et reçoit la chaîne "42" et la convertit silencieusement.

\n\n
declare(strict_types=1);\n\nfunction calculateTotal(int $price, int $quantity): int {\n    return $price * $quantity;\n}\n\n// Cela déclenchera une TypeError, pas une conversion silencieuse\necho calculateTotal('100', 2); /                

Blogs

Book Recommendations