Dominando las Code Reviews: Una Guía para Revisores y Autores

Si le preguntas a un desarrollador junior cuál es su trabajo, dirá "escribir código". Si le preguntas a un senior, dirá "resolver problemas". Pero si le preguntas a un Staff Engineer, podría decir "leer y revisar código".

A medida que creces en tu carrera, pasarás más tiempo leyendo código que escribiéndolo. La Code Review (revisión de código) es el mecanismo más importante para mantener la calidad del código, compartir conocimiento y mentorear a los miembros del equipo.

Sin embargo, a menudo es una fuente de ansiedad. Los autores temen a la crítica; los revisores temen al conflicto. Esta guía explora cómo convertir las code reviews de una tarea dolorosa en un superpoder para tu equipo.

La Filosofía: No Se Trata de Ti

La primera regla de la code review es: Estamos criticando el código, no a la persona.

• Mal: "Rompiste el build con este cambio."
• Bien: "Este cambio parece causar un fallo en el build."

Suena a un cambio semántico sutil, pero cambia la dinámica de acusación a colaboración.

Para Autores: El Arte del Pull Request

Una gran code review comienza antes de que abras el PR. Tu objetivo es hacer el trabajo del revisor lo más fácil posible.

1. El Contexto es el Rey

Nunca abras un PR con una descripción en blanco. Como mínimo, incluye:

• Qué hace este cambio.
• Por qué es necesario (Enlace al ticket/issue).
• Cómo se probó (Capturas de pantalla, videos o salida de CLI).

2. El Tamaño "Ricitos de Oro"

Un estudio de Cisco Systems encontró que la capacidad de un revisor para encontrar defectos cae significativamente después de revisar 200-400 líneas de código a la vez.

• Muy Pequeño: Corregir un error tipográfico (a menos que sea urgente).
• Muy Grande: "Refactorización de todo el sistema de autenticación" (2,000 líneas).
• Justo: Una unidad lógica de trabajo (ej. "Agregar endpoint de login de usuario").

Si tu PR es muy grande, apílalo (stack it). Divídelo en PRs más pequeños y dependientes.

3. Auto-Revisión (Self-Review)

Antes de asignar un revisor, lee tu propio diff. Te sorprenderá cuántos errores tontos (console.logs, código comentado) encuentras tú mismo. Un diff limpio muestra respeto por el tiempo de tu revisor.

Para Revisores: Qué Buscar

Cuando abras una revisión, no busques solo puntos y comas faltantes. Piensa en capas.

Capa 1: Arquitectura y Diseño (El "Panorama General")

• ¿Pertenece este cambio aquí?
• ¿Es escalable?
• ¿Introduce deuda técnica?
• Acción: Si el diseño es incorrecto, deja de revisar los detalles. Discute el enfoque primero.

Capa 2: Funcionalidad y Bugs

• ¿Realmente funciona?
• ¿Se manejan los casos borde? (Null checks, listas vacías, estados de error)
• ¿Hay alguna vulnerabilidad de seguridad? (Inyección SQL, XSS)

Capa 3: Legibilidad y Mantenibilidad

• ¿Son descriptivos los nombres de variables? (x vs userIndex)
• ¿Es la lógica demasiado compleja? (Bucles anidados, funciones masivas)
• ¿Entenderá esto un desarrollador dentro de seis meses?

Capa 4: Estilo y Nits (La Capa "Automatizada")

• Indentación, espaciado, paréntesis.
• Pro Tip: Automatiza esto con Prettier/ESLint. Los humanos no deberían perder tiempo discutiendo sobre comas.

La Trampa del "Nitpick"

Todos hemos estado ahí. Envías un algoritmo complejo y el revisor comenta: "Por favor, agrega una nueva línea al final del archivo."

Aunque el estilo importa, enfocarse solo en nits (detalles menores) es desmoralizante. Se siente como "bike-shedding".

La Regla de Oro:
Si un comentario es puramente subjetivo o una preferencia menor, etiquétalo como "Nit" o "Non-blocking".

"Nit: Prefiero const aquí, pero siéntete libre de ignorarlo."

Esto señala al autor: "Apruebo tu lógica, esto es solo una sugerencia para pulir."

Manejando Desacuerdos

Los desacuerdos son saludables. Significan que a la gente le importa. Pero pueden volverse tóxicos si se manejan mal.

1. Haz Preguntas, No Des Órdenes:
   • En lugar de: "Mueve esto a una función de utilidad."
   • Prueba: "¿Qué piensas de mover esto a una función de utilidad para mejorar la reutilización?"
2. Súbete a una Llamada:
   • Si un hilo de comentarios va y viene más de 3 veces, deja de escribir. Haz una videollamada o ve a su escritorio. El texto es un medio terrible para los matices.
3. Disagree and Commit (Discrepar y Comprometerse):
   • A veces no hay una respuesta "correcta". Si el autor tiene una razón válida y no es un problema crítico, déjalo pasar. La confianza es más importante que tener la razón al 100%.

Conclusión

La code review es una habilidad, igual que programar. Requiere empatía, claridad y paciencia.

• Autores: Escriban PRs ricos en contexto y respeten el tiempo de su revisor.
• Revisores: Busquen problemas arquitectónicos primero, sean amables y distingan entre "debe arreglarse" y "sería bueno tener".

Cuando se hace bien, la code review no solo produce mejor código; produce mejores ingenieros.