Revisión de código en PHP: 10 errores que enfurecen a los seniors

Introducción: ¿Por qué obligan a reescribir tu código PHP?

Enviaste un Pull Request, lleno de confianza de haber escrito un código perfecto. Pasa una hora y ves 15 comentarios de un desarrollador senior. ¿Te suena familiar? El code review en PHP no es solo una formalidad, sino un verdadero examen de madurez. Los seniors no ven el código como un conjunto de instrucciones, sino como un sistema que vivirá y evolucionará.

En este artículo analizaremos las observaciones más frecuentes que recibes en las revisiones. No te enseñaremos sintaxis — ya sabes cómo declarar una variable. Hablaremos sobre la cultura del código, la arquitectura y las trampas que convierten un código funcional en una pesadilla de mantenimiento. Prepárate: será doloroso, pero útil.

1. Números y cadenas mágicas: "¿Qué significa 42?"

El error más común y más irritante. Un senior ve en el código if ($status == 3) e inmediatamente pone un punto negativo. El número 3 es una constante mágica. En un mes, ni tú mismo recordarás qué significa. Y un nuevo desarrollador tendrá que adivinar: ¿es el estado "Publicado", "En borrador" o "Eliminado"?

Mal:

if ($order->getStatus() == 3) {\n    $order->sendNotification();\n}

Bien:

class OrderStatus {\n    const PENDING = 1;\n    const CONFIRMED = 2;\n    const SHIPPED = 3;\n    const DELIVERED = 4;\n}\n\nif ($order->getStatus() === OrderStatus::SHIPPED) {\n    $order->sendNotification();\n}

El uso de constantes con nombre hace que el código sea autodocumentado. No solo escribes código — estás contando una historia. Esta es una de las principales php best practices que los juniors suelen ignorar.

2. God-objects y monstruos de 500 líneas

"¡Esta clase lo hace todo!" — una frase que hace temblar a cualquier senior. Cuando una clase se encarga de enviar correos electrónicos, generar PDFs y trabajar con la base de datos, viola el principio de responsabilidad única (SRP). Esa clase es imposible de probar, difícil de modificar y garantiza que se romperá ante la más mínima refactorización.

Señales de un God-object:

\n
• La clase tiene más de 200-300 líneas
\n
• Un método tiene más de 20-30 líneas
\n
• El nombre de la clase termina en "Manager" o "Helper"
\n
• Los métodos aceptan 5+ parámetros
\n

La solución es simple: ¡divide! Extrae la lógica a servicios, repositorios, handlers. La refactorización en PHP comienza con algo pequeño: crea una clase que haga solo una cosa, pero que la haga bien.

3. Trabajo "crudo" con SQL a través de PDO

Sí, PDO protege contra inyecciones si usas prepared statements. Pero un senior quiere ver una abstracción, no SQL crudo en el controlador. ORMs como Eloquent o Doctrine son el estándar. Si el proyecto es pequeño, usa al menos un Query Builder.

Antipatrón:

$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');\n$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?');\n$stmt->execute([$email]);\n$user = $stmt->fetch();

Enfoque correcto:

class UserRepository {\n    public function findByEmail(string $email): ?User {\n        return User::where('email', $email)->first();\n    }\n}

Trabajar a través de un repositorio permite cambiar fácilmente la fuente de datos (por ejemplo, migrar a caché Redis) sin reescribir todo el proyecto. Esta es la calidad del código PHP que se valora como oro.

4. Ignorar strict_types

PHP es un lenguaje de tipado dinámico, pero eso no es excusa para escribir código como en 2005. Declarar declare(strict_types=1); al inicio de cada archivo es una señal de profesionalismo. Un senior odia cuando una función espera un int y recibe una cadena "42" y la convierte silenciosamente.

declare(strict_types=1);\n\nfunction calculateTotal(int $price, int $quantity): int {\n    return $price * $quantity;\n}\n\n// Esto lanzará un TypeError, no una conversión silenciosa\necho calculateTotal('100', 2); /