Code review en PHP: qué revisar y cómo dar retroalimentación en la práctica

Introducción: por qué el code review no es sobre control, sino sobre crecimiento

El code review (revisión de código) en PHP no es un procedimiento arcaico de control del jefe sobre el subordinado. Es un diálogo profesional entre desarrolladores, orientado a mejorar la calidad del código, difundir el conocimiento dentro del equipo y prevenir errores en etapas tempranas. Sin embargo, como muestra la práctica, muchos desarrolladores PHP (especialmente al inicio) o temen la revisión o la convierten en una formalidad vacía.

En este artículo, analizaremos en qué fijarse concretamente durante un code review de código PHP, cómo formular observaciones para no ofender a un colega y cómo sacar el máximo provecho de este proceso. El material se basa en la experiencia real de trabajo con proyectos en PHP 7.4+ y frameworks como Laravel y Symfony.

1. Qué revisar en el código PHP: lista de verificación práctica

No existe una lista universal, pero para proyectos PHP se pueden destacar 5 áreas clave que definitivamente deben pasar por el filtro de la revisión.

1.1. Seguridad (Security)

PHP es un lenguaje donde es fácil cometer una vulnerabilidad. Lo primero que revisamos:

\n
• Inyección SQL: ¿se utilizan consultas preparadas (PDO / prepared statements) en lugar de concatenación de cadenas?
\n
• XSS (Cross-Site Scripting): ¿se escapa la salida mediante htmlspecialchars() o motores de plantillas (Blade, Twig)?
\n
• Protección CSRF: ¿hay tokens en los formularios que modifican el estado?
\n
• Validación de entrada: ¿se verifica el tipo y la longitud de los datos en el lado del servidor?
\n

// Malo: concatenación en SQL\n$query = "SELECT * FROM users WHERE id = " . $_GET['id'];\n\n// Bueno: consulta preparada con PDO\n$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');\n$stmt->execute(['id' => $_GET['id']]);\n

1.2. Arquitectura y SOLID

Incluso si el proyecto no es empresarial, se deben cumplir los principios básicos:

\n
• Responsabilidad única: ¿la clase/método no hace demasiado?
\n
• Inversión de dependencias: ¿el código usa interfaces en lugar de clases concretas?
\n
• Ausencia de objetos divinos: ¿no hay clases de más de 1000 líneas?
\n

1.3. Estilo y estándares PSR

Para PHP esto es crítico. Verificamos el cumplimiento de PSR-12 (estilo de codificación):

\n
• Sangría: 4 espacios, no tabulaciones.
\n
• Llaves en nueva línea para clases y métodos.
\n
• Nomenclatura correcta: camelCase para métodos, snake_case para variables (a menos que se haya acordado otra cosa en el proyecto).
\n

1.4. Rendimiento

En PHP es fácil escribir código lento. Buscamos:

\n
• Consultas en bucle (problema N+1) — en su lugar, use carga ansiosa (Eager Loading) en el ORM.
\n
• Ignorar la caché: cálculos repetidos de los mismos datos.
\n
• Funciones ineficientes: por ejemplo, in_array() en un array grande es mejor reemplazarlo por isset($hash[$key]).
\n

// Malo: consulta en bucle\nforeach ($users as $user) {\n    $posts = DB::table('posts')->where('user_id', $user->id)->get();\n}\n\n// Bueno: una sola consulta con carga ansiosa\n$users = User::with('posts')->get();\n

1.5. Manejo de errores y tipado

\n
• ¿Hay strict_types al inicio del archivo?
\n
• ¿Se utilizan tipos para los argumentos y valores de retorno?
\n
• ¿Se manejan las excepciones, en lugar de silenciarlas con un try-catch vacío?
\n

2. Cómo dar retroalimentación: de "esto está mal" a "mejoremos esto"

La habilidad más difícil en el code review no es encontrar un error, sino presentarlo correctamente. Una mala retroalimentación mata la motivación. Una buena enseña y une al equipo.

2.1. La regla del "Sándwich"

Relleno