Code review en PHP: qué revisar y cómo dar retroalimentación

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

Introducción: por qué el code review no se trata de "encontrar errores"

El code review (revisión de código) es una de las herramientas más efectivas para mejorar la calidad de un producto de software. En la comunidad PHP, donde a menudo se encuentra el legado de "código espagueti" y una mezcla de estilos procedural y OOP, una revisión competente se vuelve especialmente importante. Sin embargo, muchos desarrolladores lo perciben como una "cacería de errores" o, peor aún, como una forma de autoafirmarse. En realidad, el objetivo del code review es transferir conocimiento, garantizar la uniformidad de la base de código y prevenir problemas potenciales antes de que lleguen a producción.

En este artículo, analizaremos en qué aspectos específicos hay que fijarse al revisar código PHP y cómo dar retroalimentación para que el equipo se fortalezca, no se ofenda.

1. Qué revisar en el código PHP: lista de verificación del revisor

Para que la revisión sea sistemática y no caótica, utilice la siguiente lista de verificación. Está dividida en categorías clave.

1.1. Seguridad (Security)

PHP es un lenguaje donde los errores de seguridad son costosos. Verifique:

Inyección SQL: ¿Se utilizan consultas preparadas (PDO o MySQLi)? Está prohibida la concatenación de cadenas en las consultas.
XSS (Cross-Site Scripting): Todo el output del usuario está escapado mediante htmlspecialchars() o motores de plantillas (Twig, Blade).
Protección CSRF: ¿Hay tokens en los formularios?
Validación en el servidor: No confíe solo en la validación del lado del cliente.

<?php// MALO: Inyección SQL$query = "SELECT * FROM users WHERE id = " . $_GET['id'];

// BUENO: PDO con prepared statement$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");$stmt->execute(['id' => $_GET['id']]);?>

1.2. Cumplimiento de los estándares PSR

PHP-FIG (Framework Interop Group) desarrolló estándares que sigue la mayoría de los proyectos modernos. Verifique:

PSR-12: sangrías (4 espacios), llaves, nomenclatura (camelCase para métodos, snake_case para variables).
PSR-4: autocarga de clases y namespaces.

Utilice herramientas automáticas (PHP CodeSniffer, PHP-CS-Fixer) para no perder tiempo formateando manualmente.

1.3. Arquitectura y SOLID

Incluso en un proyecto pequeño, los principios SOLID ayudan a evitar un "gran montón de barro". Preste atención a:

Single Responsibility: Un método/clase — una tarea. Si un método hace 3 cosas, es motivo para refactorizar.
Dependency Injection: No use new dentro de las clases, pase las dependencias a través del constructor.
Ausencia de "objetos divinos": Una clase no debe saber todo sobre el sistema.

1.4. Rendimiento

No optimice prematuramente, pero los antipatrones evidentes deben señalarse:

Consultas en un bucle (problema N+1).
Uso de funciones mysql_* (fueron eliminadas en PHP 7+).
Falta de índices en la BD para consultas frecuentes.

2. Cómo dar retroalimentación: el arte de la crítica constructiva

Incluso la lista de observaciones más correcta no será útil si la retroalimentación suena como "este código es horrible, reescríbelo". Aquí hay algunas reglas.

2.1. La regla del "sándwich"

Comience con algo positivo, luego la observación, luego el apoyo.

Positivo: "Excelente uso de interfaces, el código se ha vuelto más flexible".
Observación: "Pero aquí hay una posible vulnerabilidad XSS — escapemos la salida".
Apoyo: "Por lo demás, la lógica es correcta, después de la corrección se puede fusionar".