Code Review y Ship: De la Revisión Paranoica a la Entrega con Un Solo Comando

La revisión de código tiene un problema universal: todo el mundo cree que está siendo minucioso, pero todo el mundo está mirando el mismo conjunto de problemas.

¿Es clara la nomenclatura? ¿Es obviamente incorrecta la lógica? ¿Se manejan los casos extremos? Estas son todas preguntas válidas, pero todas son superficiales — lo que realmente causa incidentes en producción suele ser lo más profundo:

Queries N+1.
Condiciones de carrera.
Violaciones de límite de confianza.
Índices faltantes que hacen que las queries expiren bajo alta carga.
Lógica de reintento sin idempotencia, causando corrupción de estado en los reintentos.

Estas son las cosas que tus compañeros de equipo podrían no detectar en la revisión — porque el cerebro humano no está diseñado para ejecutar cinco escenarios de fallo simultáneamente.

El /review de Gstack hace exactamente eso: sistemáticamente, sin brechas, escanea en busca de problemas de alto riesgo.

`/review`: La Lista de Verificación del Ingeniero Senior Paranoico

/review no es "ayúdame a mirar este código." Tiene un framework de revisión estructurado detrás que cubre estas dimensiones cada vez:

Rendimiento y Base de Datos

¿Hay queries N+1? ¿Se están activando solicitudes de base de datos dentro de bucles?
¿Tienen las nuevas queries índices correspondientes? ¿Reducirán la velocidad las queries de alta frecuencia a medida que crecen los datos?

Concurrencia y Estado

¿Hay condiciones de carrera inseguras?
¿Está correctamente protegido el estado compartido entre solicitudes?

Límites de Confianza

¿Se está validando la entrada externa?
¿Puede la entrada del usuario llevar payloads maliciosos que eviten la lógica?

Manejo de Errores

¿Tiene la lógica de reintento protección de idempotencia?
Si falla una llamada a API externa, ¿sigue siendo consistente el estado del sistema?
¿Alguna posibilidad de fallo parcial — algunas cosas escritas, otras no?

Gestión de Recursos

¿Se liberan correctamente las conexiones, archivos y memoria después de su uso?
¿Hay cargas huérfanas o problemas de aislamiento de datos?

Cuando termina, /review categoriza los problemas como "Crítico," "Alto" o "Medio," y da la ubicación exacta y la sugerencia de corrección para cada uno — no "puede haber un problema aquí," sino "la query en la línea 47 empezará a ir lenta cuando el recuento de usuarios supere los 10K, porque le falta un índice — añade un índice compuesto en user_id."

Integración con Greptile: Cobertura de Revisión de Dos Capas

Si tu repositorio está conectado a Greptile (una herramienta de revisión automatizada de PR), /review añade un paso extra: leer los comentarios de Greptile y categorizarlos:

Problemas válidos: añadidos a los hallazgos críticos, bloqueados hasta que se resuelvan
Ya arreglados: respuesta automática para confirmar
Falsos positivos: automáticamente objeta con una explicación

La lógica de diseño: Greptile escanea patrones, Gstack hace juicios — dos capas de filtrado, menor tasa de omisiones. Gstack también registra los falsos positivos confirmados, para que el mismo patrón se salte automáticamente en el futuro — se vuelve más inteligente con el tiempo, no hay necesidad de re-explicar cada vez.

`/ship`: El SOP del Release Engineer

/ship no es "sube mi código." Es una versión automatizada de una lista de verificación de lanzamiento completa:

Sync main — confirma que tu rama está sincronizada con main, evita conflictos de merge
Ejecutar tests — ejecuta todos los tests, confirma que no hay regresiones
Resolver problemas de Greptile — maneja los problemas abiertos marcados por Greptile
Push de rama — empuja a remoto
Abrir PR — crea una pull request con una descripción clara

Seis pasos, un comando.

Esto puede no sonar complicado, pero ¿alguna vez te ha pasado esto: emocionado después de escribir código, push directo, luego te das cuenta de que no ejecutaste los tests, la rama no estaba sincronizada, la descripción de la PR está vacía — luego un revisor la devuelve, y pasas más tiempo limpiando que el que pasaste escribiendo la funcionalidad?

/ship existe para que "este proceso mecánicamente correcto" no dependa de tu estado mental — si estás contra una deadline a medianoche, si acabas de ser interrumpido por un mensaje de Slack — la lista de verificación de lanzamiento se ejecuta con la misma calidad.

El Orden Correcto: `/review` Luego `/ship`

Siempre /review primero, luego /ship — no los ejecutes simultáneamente, no saltes la revisión e vayas directo a ship.

La razón es directa: /ship solo confirma que el proceso es correcto, no la calidad del código. No le importa si tienes queries N+1 — solo le importa si la rama está sincronizada y los tests pasaron.

Flujo correcto:

Implementación completa
    ↓
/review  ← encontrar problemas, arreglar problemas
    ↓
Problemas resueltos, todos los hallazgos críticos atendidos
    ↓
/ship  ← ejecutar lista de verificación de lanzamiento, push

A veces estás seguro de que "este cambio es pequeño, no necesita revisión" — puedes saltarla, nadie te detiene. Pero si algo sale mal, mirarás atrás y desearás haberla ejecutado.

Un Detalle que Vale la Pena Saber

Cuando /review se ejecuta, lee tu git diff — está mirando el código que cambiaste, no todo el codebase.

Esto importa porque significa dos cosas:

No irá lento porque tu codebase es grande — solo mira el alcance del cambio
Los problemas que encuentra son "problemas introducidos por este cambio," no "todos los problemas en todo el codebase"

Así que si tienes un gran codebase heredado, no te preocupes de que ejecutar /review vaya a producir cientos de problemas antiguos — solo le importa lo que cambiaste esta vez.

Calidad de código confirmada, proceso de entrega automatizado — siguiente es la parte más única de Gstack: darle a la IA ojos reales para que realmente vea tu app.

→ QA y Browse: Dale Ojos a la IA para que "Vea" Realmente tu App

Volver a la Visión General de la Serie

Esta es la cuarta parada de la serie Gstack, enfocada en /review y /ship. Para el camino de lectura completo y otros temas de artículos, vuelve al Curso Gstack para Principiantes.

/review: La Lista de Verificación del Ingeniero Senior Paranoico