Code Review — qué es, cómo funciona la revisión de código y la verificación de PR

Qué es Code Review

Code review es una verificación sistemática del código por parte de colegas antes de su integración. En el contexto de Git, esto significa: un desarrollador crea un pull request con cambios, asigna revisores, y estos estudian el diff, dejan comentarios y emiten un veredicto. Un revisor puede solicitar cambios, aprobar el PR o dejar un comentario general.

La revisión de código persigue cinco objetivos: mejorar la calidad del código (detectar defectos antes de que lleguen a producción), difundir conocimiento (el revisor aprende nuevos enfoques, el autor recibe retroalimentación), garantizar estándares (verificar el cumplimiento del estilo de código y las decisiones arquitectónicas), reducir el bus factor (más de un desarrollador conoce el código) y construir una cultura de responsabilidad (el autor escribe con más cuidado sabiendo que su código será revisado).

Lo opuesto a la revisión de código es un blind commit: un desarrollador sube cambios a una rama compartida sin revisión. Este enfoque solo es aceptable en proyectos unipersonales o para hotfix urgentes con revisión posterior. En el desarrollo profesional en equipo, la revisión de código es un paso obligatorio para cualquier cambio, incluyendo actualizaciones de documentación y configuración.

Qué verificar en Code Review

La revisión de código debe ser sistemática, no caótica. Los revisores experimentados verifican el código en un orden específico: primero arquitectura y lógica, luego pruebas, después seguridad y rendimiento, y solo al final — estilo y nombres. Este orden garantiza que los problemas críticos se detecten antes de que el revisor se canse.

Arquitectura y lógica: ¿resuelve el código la tarea?, ¿hay abstracciones excesivas?, ¿se siguen los principios SOLID y DRY? El código complejo que es difícil de entender en una primera lectura es una señal de que se necesita refactorización. El revisor debe asegurarse de que el código haga exactamente lo que especifica la tarea y no tenga efectos secundarios fuera de su responsabilidad.

Pruebas: ¿cubren las nuevas pruebas todos los escenarios? — positivos, negativos, casos límite. ¿Pasan las pruebas existentes después de los cambios? ¿Hay pruebas inestables que fallan de manera inconsistente? Seguridad: ausencia de inyecciones SQL, XSS, fugas de datos sensibles a través de logs o respuestas de API. Rendimiento: eficiencia de algoritmos, consultas excesivas a BD, fugas de recursos.

• Arquitectura — corrección de la solución, cumplimiento de SOLID, ausencia de sobreingeniería.
• Lógica — manejo de todos los escenarios, incluyendo errores y casos límite.
• Pruebas — cobertura de nuevos cambios, pruebas existentes no rotas.
• Seguridad — inyecciones, XSS, CSRF, fugas de datos a través de logs.
• Rendimiento — complejidad de algoritmos, consultas N+1, fugas de memoria.

Tamaño de Revisión: por qué 400 líneas es el máximo

El límite de tamaño del PR es la métrica más importante de la eficacia de la revisión de código. Un estudio de Cisco (2015) y experimentos posteriores de SmartBear y Google mostraron que cuando el volumen de revisión supera las 400 líneas, la capacidad del revisor para encontrar defectos disminuye drásticamente. Si un PR supera las 400 líneas, los defectos se detectan con una probabilidad no superior al azar.

Tamaño óptimo: 200–400 líneas por PR. Este volumen se puede revisar en 30–60 minutos manteniendo la concentración. Google recomienda no más de 200 líneas por ronda de revisión con concentración total. Si los cambios son mayores, la tarea debe descomponerse en varios PR secuenciales, cada uno con un cambio lógicamente completo.

Tiempo de revisión: dentro de las 24 horas desde la creación del PR. Si la revisión se prolonga varios días, se pierde el contexto de la tarea y el autor tiene que dedicar tiempo a restaurarlo al responder comentarios. Los equipos con una sólida cultura de revisión de código establecen SLA: por ejemplo, 4 horas para cambios críticos y 24 horas para los regulares.

Cómo escribir buenos comentarios de revisión

El tono de los comentarios es fundamental para la eficacia de la revisión de código. Un comentario como “Esto está mal” provoca una reacción defensiva y no aporta información útil al autor. Una mejor formulación es una pregunta-sugerencia: “¿Qué opinas de este enfoque?”, “Esto podría causar un NPE si user == nil. ¿Quizás añadir un guard?”. Las preguntas son menos confrontativas y estimulan el debate.

Un buen comentario incluye tres partes: qué está mal, por qué es un problema y cómo solucionarlo. Ejemplo: “Este bucle usa O(n²) debido a un contains anidado, lo que podría ralentizar con 10k+ registros. Prueba a reemplazarlo con un Set para búsqueda O(1).” Esta formulación identifica el problema, explica su importancia y sugiere una solución — el autor no tiene que adivinarla.

GitHub y GitLab admiten suggestions — propuestas de cambio de código en línea. Un revisor puede escribir: “```suggestion Filter empty strings before processing```” y el autor puede aplicar el cambio con un clic. Esto acelera las correcciones menores y reduce el número de rondas de revisión. Para cambios grandes, es mejor escribir un comentario general en lugar de incrustar grandes bloques en una sugerencia.

# Plantilla para un buen comentario de code review

# MALO: "This code is wrong"
# BUENO: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Sintaxis de sugerencia de GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Flujo de trabajo de Code Review en equipo

Un flujo de trabajo eficaz se basa en cuatro etapas. Primera — el autor prepara el PR: escribe un título claro (por ejemplo, “feat: add password reset screen”), añade una descripción de los cambios, enlaces a la tarea en el tracker e instrucciones de prueba. Segunda — el autor asigna revisores mediante auto-assign (basado en CODEOWNERS) o manualmente.

La tercera etapa — el revisor verifica el código y deja comentarios. La cuarta — el autor realiza correcciones, responde a los comentarios y solicita una nueva revisión. El ciclo se repite hasta obtener la aprobación. Tras la aprobación, el autor realiza la fusión (o el bot lo hace). La automatización mediante Mergify o GitHub Auto-merge acelera la etapa final.

Un elemento importante del flujo de trabajo es la gestión de PR obsoletos. Si un PR permanece sin revisión más de 3 días, el proceso se bloquea. Soluciones: rotación de revisores (si el asignado no está disponible), notificaciones a través de Slack/Teams, límite de tiempo para revisión (SLA). En algunos equipos, un PR sin revisión durante más de 7 días se cierra automáticamente y el autor crea uno nuevo tras sincronizar con main.

• Creación del PR — título claro, descripción, enlaces a la tarea, capturas de pantalla para cambios de UI.
• Asignación — auto-asignación mediante CODEOWNERS o selección manual de 1–2 revisores.
• Revisión — verificar en orden: arquitectura → lógica → pruebas → seguridad → estilo.
• Correcciones — el autor responde a todos los comentarios, corrige problemas bloqueantes, solicita re-revisión.
• Fusión — tras la aprobación y CI verde, el autor o el bot realiza la fusión.

Errores comunes en Code Review

El primer error — revisión superficial. El revisor escanea rápidamente el diff sin profundizar en la lógica y hace clic en Approve. Causas: PR grande, fecha límite, fatiga. Consecuencias: los errores llegan a producción. Solución: si no hay tiempo para una revisión de calidad — escribir honestamente “No puedo revisar hoy, trasládenlo a mañana” en lugar de una aprobación formal.

El segundo error — crítica excesiva (nitpicking). El revisor deja decenas de comentarios sobre el estilo de formato, nombres de variables, detalles triviales. Esto desmotiva al autor y alarga la revisión. Solución: la guía de estilo y los linters deben verificar el estilo automáticamente. Una persona en la revisión verifica lógica, arquitectura y seguridad.

El tercer error — revisión sin preguntas. Si el revisor solo publica Request Changes y Approve pero no hace preguntas, pierde la oportunidad de aprender algo nuevo. El mejor indicador de una revisión saludable es la presencia de debates en los que ambas partes aprenden algo nuevo. Si una revisión es un monólogo de un participante, el proceso está roto.

• Revisión superficial — Approve sin análisis profundo. Solución: no revisar si no tienes tiempo.
• Nitpicking — criticar el estilo que debería verificar el linter. Solución: automatizar las comprobaciones de estilo.
• Preferencia personal — “Yo lo habría escrito de otra manera”. Solución: el código debe funcionar, no gustarle al revisor.
• Demora — revisión de más de 24 horas. Solución: SLA en revisión, escalación ante incumplimiento.
• Ignorar el contexto — revisar código sin entender la tarea. Solución: leer la descripción del PR antes del diff.