Lista de Verificación de Revisión de Código Laravel para 2026

Contrató a un proveedor para construir su aplicación Laravel. La demo funciona, las pantallas cargan y la factura está en camino. Lo que hay bajo el capó, sin embargo, es una cuestión aparte, y una que la mayoría de los equipos solo hace después de que algo se rompe.

Esa brecha de confianza es la razón por la que elaboramos esta guía. La lista a continuación es la misma que usan nuestros revisores al auditar bases de código Laravel, y refleja el marco detrás de cada revisión de código Laravel que realizamos para clientes. Muchos equipos heredan una base de código Laravel en lugar de cuestionarla, así que ejecute los pasos a continuación antes de su próxima entrega o lanzamiento y detectará lo que más cuesta corregir más adelante.

Estándares de Codificación Laravel (PSR-12)

El código que ignora las convenciones es difícil de leer, difícil para incorporar nuevos desarrolladores y un imán para los errores. PSR-12 es el estándar PHP-FIG que el ecosistema Laravel sigue por defecto, y una revisión comienza aquí porque cada comprobación posterior se apoya en una base de código que se puede leer. Tratamos esta capa como requisito indispensable, no como algo agradable de tener.

Qué Verificamos en Formato y Nomenclatura

Tres patrones que marcamos primero al abrir una nueva base de código:

Indentación mixta, líneas de más de 120 caracteres, sin type hints en ningún lugar.
Modelos nombrados en plural (Users en lugar de User), controladores sin el sufijo Controller.
Columnas en snake_case junto a columnas en camelCase en la misma migración.

Una revisión limpia espera indentación de 4 espacios, modelos en PascalCase, métodos en camelCase, columnas en snake_case, nombres de tablas en plural y type hints en cada parámetro y valor de retorno. Los bloques PHPDoc deben explicar el porqué en los métodos públicos.

Pint y Larastan en CI

Las herramientas refuerzan los estándares de codificación Laravel para que los revisores puedan centrarse en la lógica. Pint es el formateador oficial de Laravel, y Larastan añade análisis estático consciente de Laravel sobre PHPStan. Ambos deben ejecutarse en integración continua, porque las convenciones solo se mantienen cuando la canalización bloquea las fusiones que las rompen.

Un paso mínimo de CI tiene este aspecto:

vendor/bin/pint --test
vendor/bin/phpstan analyse --memory-limit=2G

Cuando cualquiera de los comandos falla, el pull request se detiene. Esa única regla previene la mayoría de la deriva de estilo en equipos de cualquier tamaño.

Lista de Verificación de Revisión de Código Laravel

Código Limpio y Arquitectura

Laravel permite lanzar rápido, que es tanto su fortaleza como su trampa. Muchas bases de código que auditamos entregaron un MVP funcional con lógica repartida entre controladores, modelos y plantillas Blade, y la limpieza posterior cuesta más que la construcción original. El código limpio en Laravel es la diferencia entre una base de código que puede extender en el segundo año y una que tiene que reescribir.

Controladores Delgados, Clases de Servicio y Clases de Acción

El trabajo de un controlador es HTTP, nada más. Cuando vemos métodos de más de 30 líneas sabemos que la lógica de negocio se ha filtrado, y la solución es una clase de servicio o una clase de acción de propósito único.

Malo:

public function store(Request $request)
{
    $data = $request->validate([
        'email' => 'required|email',
        'plan'  => 'required|in:basic,pro',
    ]);

    $user = User::create($data);
    Mail::to($user->email)->send(new WelcomeMail($user));
    Subscription::create([
        'user_id' => $user->id,
        'plan'    => $data['plan'],
    ]);

    return redirect()->route('dashboard');
}

Mejor:

public function store(RegisterRequest $request, RegisterUser $action)
{
    $action->execute($request->validated());

    return redirect()->route('dashboard');
}

El controlador ahora se lee de un vistazo. La clase de acción es comprobable por sí sola y reutilizable desde un comando de consola o un trabajo en cola, que es lo que hace que los refactors sean seguros.

Form Requests y Policies

La validación en línea y la autorización en línea son dos de los atajos más comunes que desenganchamos. Las reglas de validación pertenecen a las clases Form Request, y la autorización pertenece a los Policies registrados contra el modelo. Ambos movimientos reducen los controladores y colocan las reglas donde los desarrolladores esperan encontrarlas, lo que acelera la incorporación y reduce los errores introducidos por la siguiente persona que toca el archivo.

Si sigue encontrando controladores con 200 líneas de responsabilidades mixtas, el problema es más profundo que una refactorización, y puede ser el momento de recurrir a un consultor de arquitectura de software antes de que la limpieza se convierta en una reescritura.

Eloquent y Consultas de Base de Datos

Eloquent es elegante y peligroso a partes iguales. El ORM oculta el costo de una consulta, y un foreach descuidado lanza cientos de llamadas a la base de datos bajo la superficie. Las auditorías de rendimiento a menudo comienzan en esta capa.

Consultas N+1 y Carga Anticipada

La consulta N+1 es el error de rendimiento más común en Laravel que encontramos. El patrón parece inocente en pantalla:

$posts = Post::all();

foreach ($posts as $post) {
    echo $post->author->name; // one extra query per post
}

La solución es with():

$posts = Post::with('author')->get();

foreach ($posts as $post) {
    echo $post->author->name; // no extra queries
}

Añada Model::preventLazyLoading() en su AppServiceProvider para entornos que no sean de producción y Laravel lanzará una excepción en el momento en que se produzca la carga diferida. El error aparece en su suite de pruebas en lugar de bajo carga de producción.

Índices, Asignación Masiva y Migraciones

Tres comprobaciones de la capa de base de datos que realizamos en cada auditoría:

Las claves foráneas y las columnas filtradas frecuentemente tienen índices.
Los modelos declaran $fillable o $guarded deliberadamente, para que una entrada no autorizada no pueda sobrescribir campos de solo administrador.
Las migraciones tienen métodos down() funcionales, para que los rollbacks no corrompan los datos de producción.

El tercero importa más de lo que la mayoría de los equipos se dan cuenta. Una migración sin rollback es una puerta de sentido único, y esa puerta siempre se abre en el peor momento posible.

Mejores Prácticas de Seguridad en Laravel

La seguridad es donde los traspasos de proveedores fallan de forma más dolorosa. Según el Informe de Costo de Violación de Datos de IBM 2025, el costo promedio global de una violación ahora es de USD 4,44 millones, y USD 10,22 millones en los Estados Unidos. Una revisión de código es el momento más económico para encontrar las brechas que conducen a esas cifras.

Entorno, CSRF, XSS y Subida de Archivos

Estas son las mejores prácticas de seguridad en Laravel más pasadas por alto en nuestras auditorías. Una lista de verificación rápida:

APP_DEBUG=false y APP_ENV=production en entornos de producción.
.env excluido del control de versiones y que devuelva 403 por HTTP.
Middleware CSRF habilitado en cada ruta que cambia estado.
Blade {{ }} utilizado para la salida, con {!! !!} solo después de una sanitización explícita.
Subidas de archivos validadas por tipo MIME, tamaño y extensión, luego almacenadas fuera del directorio público.

El OWASP Top 10 cubre las categorías más amplias contra las que estas comprobaciones defienden. Mapear los hallazgos de su auditoría a las categorías de OWASP le da al informe una estructura que su equipo de seguridad reconocerá.

Autenticación, Limitación de Velocidad y Auditorías de Dependencias

Las contraseñas deben hashearse con bcrypt o Argon2, nunca con MD5 o SHA1. Las APIs deben usar Laravel Sanctum o Passport, con el middleware throttle aplicado a los endpoints de inicio de sesión y restablecimiento de contraseña para detener la fuerza bruta. El comando composer audit debe ejecutarse en CI en cada compilación, para que una vulnerabilidad recién publicada en una dependencia no pase desapercibida durante semanas.

Un solo paquete desactualizado puede deshacer todas las demás comprobaciones de esta lista. Por eso una revisión sin auditoría de dependencias está incompleta.

Optimización del Rendimiento en Laravel

Los problemas de rendimiento rara vez llegan como un solo error. Se acumulan en varias capas, y una revisión expone las capas que son silenciosamente costosas. La optimización del rendimiento en Laravel durante una auditoría es diagnóstico, no implementación, por lo que el informe le dice dónde vive el costo y por qué.

Algunas cosas que verificamos en cada proyecto:

Las cachés de rutas, configuración, vistas y eventos están calientes en producción (php artisan route:cache, config:cache, view:cache, event:cache).
El trabajo pesado (correos electrónicos, exportaciones, llamadas a APIs de terceros, procesamiento de imágenes) se despacha a colas con un driver real como Redis, no de forma síncrona.
Cada endpoint de lista está paginado, sin Model::all() en una tabla que crece.
Una capa de caché se sitúa delante de las lecturas costosas, con valores razonables de tiempo de vida.
OPcache está habilitado a nivel de PHP.
Los hallazgos de Telescope o Laravel Debugbar del entorno de staging han sido revisados.

Un patrón común en los MVPs es desplegar sin ninguno de los anteriores y descubrir el costo cuando el tráfico se duplica después de un lanzamiento. El equilibrio está documentado en nuestro análisis de los costos ocultos que aparecen más tarde.

Pruebas y Fiabilidad

Una aplicación Laravel sin pruebas está a un refactor de la inactividad en producción. La base de código no necesita un 100% de cobertura para ser segura, pero los caminos críticos absolutamente sí. Lo que buscamos es una suite de Pest o PHPUnit que se ejecute en verde en integración continua, pruebas de funcionalidades en cada flujo que toca los ingresos (autenticación, pago, CRUD básico), factories definidas para los modelos principales para que los datos de prueba sean una línea de código, el trait RefreshDatabase en cada prueba que toca la base de datos, y las APIs externas mockeadas en lugar de llamadas durante la suite.

Cuando la suite está ausente o con errores, el movimiento inicial correcto son las pruebas de caracterización del comportamiento actual, seguidas de refactorización. La cobertura construida alrededor de un contrato congelado es el único tipo en el que puede confiar más adelante, y los equipos que omiten este paso generalmente lo pagan dos veces: primero en confianza y luego en informes de incidentes.

Dependencias y Herramientas

El grafo de dependencias es a menudo la parte más ignorada de una aplicación Laravel. Los frameworks desactualizados y los paquetes abandonados representan una gran parte de las vulnerabilidades e incompatibilidades que vemos, y ejecutar en versiones con soporte se correlaciona fuertemente con la velocidad del equipo en cada encuesta de desarrolladores de los últimos años.

La lista de verificación aquí es corta pero duele si la omite. Laravel debe estar en una versión con soporte (Laravel 12 tiene soporte de seguridad hasta el 24 de febrero de 2027). PHP debe estar en 8.3 o 8.4, no anterior. El archivo composer.lock debe confirmarse y ser idéntico en las máquinas de los desarrolladores, CI y producción. No debe haber paquetes marcados como abandonados por composer audit. Pint, Larastan y Pest deben ejecutarse en CI en cada push, con Rector añadido si desea refactors de actualización automatizados en versiones de PHP y Laravel.

Qué Descubre Nuestra Lista de Verificación de Revisión de Código Laravel en Auditorías Reales

Los números cuentan la historia mejor que las promesas. En el último ciclo de auditorías de nuestro equipo, nuestros revisores registraron 82 vulnerabilidades de seguridad en 15 proyectos Laravel y PHP, 27 casos de programación de copiar y pegar, y 23 casos de conflictos de dependencias lo suficientemente graves como para bloquear los despliegues. La mayoría de esos problemas estaban en código que el equipo original consideraba listo para producción.

Las 5 Principales Señales de Alerta en Laravel

Los patrones se repiten en las auditorías, y estos cinco problemas aparecen con mayor frecuencia:

Controladores sobrecargados con validación, lógica de negocio y efectos secundarios en un solo método.
Consultas N+1 en endpoints de panel que solo aparecen bajo carga real.
.env filtrado a través de APP_DEBUG=true en una URL de staging expuesta a Internet.
Sin limitación de velocidad en el inicio de sesión o el restablecimiento de contraseña, dejando la puerta abierta a ataques de fuerza bruta.
Código generado por IA que funciona en el camino feliz y silenciosamente omite Form Requests, Policies y pruebas.

Cuando un MVP se entrega con varios de estos, el camino más limpio a seguir es una revisión estructurada seguida de mantenimiento continuo de Laravel en lugar de otra reescritura completa. Para los equipos listos para escalar el mismo stack hacia un producto de pago, nuestros servicios de desarrollo Laravel continúan donde termina el informe de revisión.

Reflexiones Finales

Una lista de verificación de revisión de código Laravel no es un sustituto del criterio de ingeniería senior, pero es la forma más económica de hacer ese criterio repetible. Seguir las establecidas las mejores prácticas de Laravel durante cada revisión, cada lanzamiento y cada traspaso de proveedor es lo que separa una aplicación que puede escalar de una que tendrá que reconstruir. El trabajo se paga solo la primera vez que evita un rollback de viernes por la noche o una divulgación de seguridad de lunes por la mañana.

Si prefiere tener un segundo par de ojos en la base de código, o simplemente no tiene el ancho de banda para ejecutar la auditoría internamente, contáctenos y definiremos el alcance de una revisión alrededor de su stack.

Lista de Verificación de Revisión de Código Laravel