Code review en PHP: qué revisar y cómo dar retroalimentación
\n\nEl code review no es solo una formalidad, sino una herramienta poderosa para el crecimiento del equipo y la mejora de la calidad del código. Para los desarrolladores principiantes de PHP, el proceso de revisión a menudo parece intimidante: "¿Y si paso por alto un error?", "¿Cómo le digo a un colega que su código es malo?". En este artículo, analizaremos en qué fijarse al revisar código PHP y cómo dar retroalimentación para que sea útil, no ofensiva.
\n\n1. Qué revisar en el código PHP: lista de verificación para el revisor principiante
\n\nEmpecemos con el aspecto técnico. Estas son las categorías principales que debe revisar durante un code review de un proyecto PHP:
\n\n- \n
- Seguridad (Security) — la zona más crítica. Verifique si hay inyecciones SQL, vulnerabilidades XSS, datos de entrada no protegidos. \n
- Cumplimiento de estándares de codificación — PSR-1, PSR-12 (o los estándares de su equipo). Esto garantiza legibilidad y uniformidad. \n
- Rendimiento — evite consultas excesivas a la base de datos, bucles no óptimos, operaciones pesadas dentro de bucles. \n
- Arquitectura y lógica — cumplimiento de los principios SOLID, DRY, KISS. ¿Se duplica el código? ¿Es la lógica demasiado compleja? \n
- Manejo de errores — ¿hay try-catch? ¿Se registran las excepciones correctamente? ¿No se suprimen los errores? \n
- Tipado y rigor — ¿el código usa strict_types? ¿Están correctamente especificados los tipos de argumentos y valores de retorno? \n
Aquí hay un ejemplo de código malo y bueno desde el punto de vista de la seguridad:
\n\n<?php\n// MALO: vulnerable a inyección SQL\n$query = "SELECT * FROM users WHERE id = " . $_GET['id'];\n$result = mysqli_query($conn, $query);\n\n// BUENO: uso de consultas preparadas\n$stmt = $conn->prepare("SELECT * FROM users WHERE id = ?");\n$stmt->bind_param("i", $id);\n$id = (int)$_GET['id'];\n$stmt->execute();\n$result = $stmt->get_result();\n?>\n\n2. Cómo dar retroalimentación: principios de una revisión constructiva
\n\nLa parte técnica es solo la mitad del trabajo. La otra mitad es la habilidad de comunicar sus observaciones de manera que el autor del código quiera corregirlas, en lugar de ofenderse o ponerse a la defensiva.
\n\nReglas básicas para la retroalimentación:
\n\n- \n
- Hable sobre el código, no sobre la persona. En lugar de "Escribiste un código horrible", diga "En este lugar hay una vulnerabilidad potencial, discutamos cómo solucionarla". \n
- Use mensajes en primera persona ("Yo"). "Veo que aquí podría ocurrir un error porque..." suena más suave que "Te equivocaste". \n
- Explique el "por qué". No solo "Usa prepared statements", sino "Los prepared statements protegen contra inyecciones SQL porque separan los datos del código de la consulta". \n
- Ofrezca alternativas. En lugar de "Esto está mal", muestre cómo se puede hacer mejor. \n
- Elogie lo bueno. No olvide destacar las soluciones acertadas: "¡Excelente idea sacar la validación a una clase separada!". \n
Ejemplo de un comentario constructivo:
\n\n<!-- COMENTARIO MALO -->\n<!-- ¿Por qué no usas tipado estricto? ¡Es lo básico! -->\n\n<!-- COMENTARIO BUENO -->\n<!-- Sugiero agregar declare(strict_types=1) al inicio del archivo. \nEsto obligará a PHP a verificar los tipos de forma estricta y evitará \nconversiones implícitas accidentales que podrían provocar errores. -->\n\n3. Errores típicos en código PHP que debe buscar durante la revisión
\n\nAquí hay una lista de problemas comunes que se encuentran en el código de desarrolladores PHP principiantes. Preste especial atención a ellos:
\n\n- \n
- Falta de validación de datos de entrada. Nunca confíe en $_GET, $_POST, $_REQUEST, $_FILES. \n
- Variables globales y arrays superglobales dentro de funciones. Esto viola la encapsulación y di