Cómo hacer una buena revisión de código

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 cub