Code review en PHP : quoi vérifier et comment donner un retour

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 la revue de code ne consiste pas à "trouver des bugs"

La revue de code est l'un des outils les plus efficaces pour améliorer la qualité d'un produit logiciel. Dans la communauté PHP, où le "code spaghetti" hérité et un mélange de styles procédural et POO sont courants, une revue compétente devient particulièrement importante. Cependant, de nombreux développeurs la perçoivent comme une "chasse aux bugs" ou, pire, comme un moyen de s'affirmer. En réalité, l'objectif de la revue de code est de transférer des connaissances, d'assurer la cohérence de la base de code et de prévenir les problèmes potentiels avant qu'ils n'atteignent la production.

Dans cet article, nous allons détailler exactement ce qu'il faut rechercher lors de la revue de code PHP, et comment donner un retour d'information qui renforce l'équipe plutôt que de provoquer des offenses.

1. Ce qu'il faut vérifier dans le code PHP : Une checklist pour le relecteur

Pour que la revue soit systématique plutôt que chaotique, utilisez la checklist suivante. Elle est divisée en catégories clés.

1.1. Sécurité

PHP est un langage où les erreurs de sécurité coûtent cher. Vérifiez :

Injection SQL : Les requêtes préparées (PDO ou MySQLi) sont-elles utilisées ? La concaténation de chaînes dans les requêtes est interdite.
XSS (Cross-Site Scripting) : Toute sortie utilisateur est-elle échappée avec htmlspecialchars() ou des moteurs de templates (Twig, Blade) ?
Protection CSRF : Y a-t-il des jetons dans les formulaires ?
Validation côté serveur : Ne vous fiez pas uniquement à la validation côté client.

<?php// MAUVAIS : Injection SQL$query = "SELECT * FROM users WHERE id = " . $_GET['id'];

// BON : PDO avec requête préparée$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");$stmt->execute(['id' => $_GET['id']]);?>

1.2. Conformité aux normes PSR

Le PHP-FIG (Framework Interop Group) a développé des normes que la plupart des projets modernes suivent. Vérifiez :

PSR-12 : Indentation (4 espaces), accolades, conventions de nommage (camelCase pour les méthodes, snake_case pour les variables).
PSR-4 : Autoloading des classes et des espaces de noms.

Utilisez des outils automatisés (PHP CodeSniffer, PHP-CS-Fixer) pour éviter de passer du temps sur le formatage manuel.

1.3. Architecture et SOLID

Même dans un petit projet, les principes SOLID aident à éviter une "grosse boule de boue". Portez une attention particulière à :

Responsabilité unique : Une méthode/classe — une tâche. Si une méthode fait 3 choses, c'est une raison de refactoriser.
Injection de dépendances : N'utilisez pas new à l'intérieur des classes ; passez les dépendances via le constructeur.
Absence d'"Objets Dieu" : Une classe ne doit pas tout savoir du système.

1.4. Performance

N'optimisez pas prématurément, mais les anti-patrons évidents doivent être signalés :

Requêtes dans les boucles (problème N+1).
Utilisation des fonctions mysql_* (elles ont été supprimées dans PHP 7+).
Absence d'index de base de données pour les requêtes fréquentes.

2. Comment donner un retour d'information : L'art de la critique constructive

Même la liste de commentaires la plus correcte ne sera pas utile si le retour sonne comme "ce code est terrible, réécrivez-le". Voici quelques règles.

2.1. La règle du "sandwich"

Commencez par un point positif, puis le commentaire, puis un soutien.

Positif : "Belle utilisation des interfaces, le code est devenu plus flexible."
Commentaire : "Mais il y a une vulnérabilité XSS potentielle ici — échappons la sortie."
Soutien : "Sinon, la logique est correcte. Après correction, cela peut être fusionné."