Revue de code en PHP : quoi vérifier et comment donner un retour d'expérience concret

Introduction : pourquoi la revue de code n'est pas une question de contrôle, mais de croissance

La revue de code (code review) en PHP n'est pas une procédure de contrôle archaïque d'un supérieur sur un subordonné. C'est un dialogue professionnel entre développeurs, visant à améliorer la qualité du code, à diffuser les connaissances au sein de l'équipe et à prévenir les erreurs dès les premières étapes. Cependant, comme le montre la pratique, de nombreux développeurs PHP (surtout les débutants) soit craignent la revue, soit la transforment en une simple formalité vide.

Dans cet article, nous allons détailler sur quoi se concentrer précisément lors d'une revue de code PHP, comment formuler des remarques sans offenser un collègue, et comment tirer le meilleur parti de ce processus. Le contenu est basé sur une expérience réelle de travail sur des projets en PHP 7.4+ et des frameworks comme Laravel et Symfony.

1. Que vérifier dans le code PHP : une liste de contrôle pratique

Il n'existe pas de liste universelle, mais pour les projets PHP, on peut identifier 5 zones clés qui doivent absolument être passées au crible de la revue.

1.1. Sécurité (Security)

PHP est un langage où il est facile de créer une vulnérabilité. On vérifie en premier :

\n
• Injection SQL : utilise-t-on des requêtes préparées (PDO / prepared statements) au lieu de la concaténation de chaînes ?
\n
• XSS (Cross-Site Scripting) : l'affichage est-il échappé avec htmlspecialchars() ou des moteurs de templates (Blade, Twig) ?
\n
• Protection CSRF : y a-t-il des jetons sur les formulaires qui modifient l'état ?
\n
• Validation des entrées : le type et la longueur des données sont-ils vérifiés côté serveur ?
\n

// Mauvais : concaténation en SQL\n$query = "SELECT * FROM users WHERE id = " . $_GET['id'];\n\n// Bon : requête préparée PDO\n$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');\n$stmt->execute(['id' => $_GET['id']]);\n

1.2. Architecture et SOLID

Même si le projet n'est pas une entreprise, les principes de base doivent être respectés :

\n
• Responsabilité unique : la classe/méthode ne fait-elle pas trop de choses ?
\n
• Inversion des dépendances : le code utilise-t-il des interfaces au lieu de classes concrètes ?
\n
• Absence d'objets divins : n'y a-t-il pas de classes de plus de 1000 lignes ?
\n

1.3. Style et normes PSR

Pour PHP, c'est crucial. On vérifie la conformité à PSR-12 (style de codage) :

\n
• Indentation : 4 espaces, pas de tabulation.
\n
• Accolades sur une nouvelle ligne pour les classes et les méthodes.
\n
• Nommage correct : camelCase pour les méthodes, snake_case pour les variables (sauf si le projet en a décidé autrement).
\n

1.4. Performances

En PHP, il est facile d'écrire du code lent. On recherche :

\n
• Requêtes dans une boucle (problème N+1) — utilisez plutôt le chargement impatient (Eager Loading) dans l'ORM.
\n
• Ignorance du cache : recalculs répétés des mêmes données.
\n
• Fonctions inefficaces : par exemple, in_array() sur un grand tableau est mieux remplacé par isset($hash[$key]).
\n

// Mauvais : requête dans une boucle\nforeach ($users as $user) {\n    $posts = DB::table('posts')->where('user_id', $user->id)->get();\n}\n\n// Bon : une seule requête avec chargement impatient\n$users = User::with('posts')->get();\n

1.5. Gestion des erreurs et typage

\n
• Y a-t-il strict_types au début du fichier ?
\n
• Utilise-t-on des types pour les arguments et les valeurs de retour ?
\n
• Les exceptions sont-elles gérées, et non étouffées par un simple try-catch ?
\n

2. Comment donner un retour d'expérience : de "c'est mauvais" à "améliorons-le"

La compétence la plus difficile dans une revue de code n'est pas de trouver une erreur, mais de la présenter correctement. Un mauvais retour tue la motivation. Un bon retour enseigne et rapproche l'équipe.

2.1. La règle du "Sandwich"

La garniture