Revisar código es una de las actividades más subestimadas del desarrollo de software.

La mayoría de los equipos la tratan como un trámite, algo que hay que aprobar antes de mergear. El resultado es que los PRs se aprueban con un “LGTM” después de dos minutos de scroll, y los problemas reales pasan de largo.

Una revisión bien hecha no es leer línea por línea buscando typos. Es entender qué intenta hacer ese código, si lo hace de la manera correcta, y si introduce riesgos que no existían antes. Eso requiere un proceso, no un instinto.

Este artículo cubre cómo estructurar ese proceso: qué revisar, en qué orden, qué preguntas hacer, y cómo detectar problemas de seguridad sin ser un experto en ciberseguridad.

Empieza por el contexto, no por el código

El error más común en code review es abrir el diff y empezar a leer desde la primera línea modificada. Antes de ver una sola línea, necesitas entender qué problema resuelve este cambio.

Lee la descripción del PR. Si no hay descripción, o si dice “fixes bug”, ya encontraste el primer problema. Un PR sin contexto obliga al reviewer a reconstruir el razonamiento del autor desde cero, y eso aumenta la probabilidad de aprobar algo que no debería aprobarse.

Lo que un buen PR debe explicar:

• Qué cambia no cómo, sino qué problema resuelve
• Por qué este approach si hay alternativas que se descartaron, decirlo
• Cómo probarlo, pasos para verificar que funciona
• Qué no cubre, scope explícito evita confusiones

Si tienes esa información antes de ver el diff, tu revisión va a ser significativamente más efectiva.

Qué revisar y en qué orden

No toda línea de código merece el mismo nivel de atención. Un buen reviewer distribuye su energía de forma inteligente.

Primero: arquitectura y flujo de datos. ¿El cambio tiene sentido a nivel de diseño? ¿Agrega una dependencia innecesaria? ¿Rompe alguna abstracción existente? Esto es lo más difícil de cambiar después.

Segundo: lógica de negocio. ¿El código hace lo que dice que hace? ¿Los edge cases están cubiertos? ¿Qué pasa si el input viene vacío, nulo, o malformado?

Tercero: seguridad. Este punto merece su propia sección.

Cuarto: legibilidad y convenciones. Nombres de variables, estructura de funciones, comentarios. Importante, pero no el punto de partida.

La mayoría de los reviewers hacen esto al revés, empiezan por los detalles de estilo y llegan agotados a lo que realmente importa.

Cómo detectar problemas de seguridad en code review

Detectar vulnerabilidades durante un code review no requiere ser un especialista en seguridad. Requiere hacerse las preguntas correctas.

Hay patrones que aparecen consistentemente en PRs problemáticos:

Entradas sin validar. ¿Los datos que vienen del exterior (usuario, API, archivo) se usan directamente sin sanitizar? Cualquier lugar donde un string externo toca una query, un path de archivo, o una llamada a sistema es candidato a revisión.

Manejo de errores que expone información. Stack traces devueltos al cliente, mensajes de error con rutas internas, logs que incluyen tokens o passwords. Esto pasa más de lo que parece.

Dependencias nuevas. Cada npm install o pip install que aparec en el diff es una superficie de ataque potencial. ¿Se revisó el paquete? ¿Tiene CVE conocidos? ¿Cuántos mantenedores activos tiene?

Secrets hardcodeados. Claves API, tokens, URLs de bases de datos. Son más comunes de lo que cualquier equipo quiere admitir.

Algunos equipos integran análisis automatizado directamente en el flujo de revisión para que estos patrones se marquen antes de que el reviewer los vea. Herramientas como Ixtli, por ejemplo, analizan el diff completo del PR contra el grafo de dependencias del proyecto, no solo las líneas cambiadas, lo que hace que ciertos tipos de vulnerabilidades sean mucho más difíciles de pasar por alto.

Cómo dar feedback que sirva

El objetivo de un comentario en un code review no es demostrar que encontraste algo malo. Es que el código mejore.

Algunas reglas que hacen una diferencia real:

Sé específico. “Este código es confuso” no ayuda. “Esta función hace tres cosas distintas, considera extraer la lógica de validación a una función separada” sí ayuda.

Distingue entre bloqueante y sugerencia. No todo comentario debe impedir el merge.

Prefija con [bloqueante], [sugerencia] o [nitpick] para que el autor sepa qué es crítico y qué es opcional.

Pregunta antes de asumir. Si algo no se entiende, pregunta. “¿Por qué se usa setTimeout aquí en lugar de un event listener?” es mejor que asumir que es un error.

Aprueba cuando está listo. No sigas agregando comentarios menores una vez que los problemas reales están resueltos. El proceso de review también tiene un costo.

Checklist para code review

Antes de aprobar un PR, recorre estos puntos:

| Área | Pregunta |

|------|---------|

| Contexto | ¿El PR tiene descripción clara de qué resuelve? |

| Diseño | ¿El cambio tiene sentido arquitectónico? |

| Lógica | ¿Los edge cases están cubiertos? |

| Seguridad | ¿Hay entradas sin validar, secretos expuestos, o dependencias nuevas sin revisar? |

| Tests | ¿Los tests cubren los casos relevantes, no solo el happy path? |

| Deuda técnica | ¿El cambio deja el código en mejor estado del que lo encontró? |

No es una lista para leer rápido. Es una lista para detenerse en cada punto.

Conclusión

Una buena revisión de código no es más lenta que una mala, es más intencional.

La diferencia está en saber qué buscar y en qué orden.

Si tu equipo trata los PRs como trámites, el problema no es el código, es el proceso.

Empezar a usar un checklist consistente, pedir descripciones reales en cada PR, y separar los comentarios bloqueantes de las sugerencias son cambios que se pueden implementar esta semana sin herramientas adicionales.

Para la parte de seguridad, revisar manualmente cada dependencia nueva o cada input sin validar es costoso en tiempo. Vale la pena evaluar qué parte de ese trabajo puede automatizarse, ixtli.app está construido específicamente para ese slice del proceso.