Code review efectivo: revisar PR sin frenar al equipo

El code review no es un filtro de calidad abstracto, es una conversación entre dos ingenieros sobre cómo se construye software. Cuando esa conversación funciona, los dos aprenden. Cuando no, se vuelve un cuello de botella emocional donde nadie quiere abrir un PR.

El mito del reviewer perfecto

No existe el reviewer que siempre encuentra el bug oculto y nunca molesta al autor. Sí existe el reviewer que:

• Tarda menos de 24 horas en responder.
• Separa los comentarios en bloqueantes, sugerencias y preguntas.
• Reconoce cuando un PR está bien aunque no lo habría hecho igual.

Si tu equipo tiene un reviewer así, hay que cuidarlo. Si sos vos, te toca serlo.

El modelo de tres lentes

Cuando abrís un PR, mirá con tres lentes, en este orden:

1. Correctness: ¿funciona? ¿Cubre los casos borde? ¿Los tipos son correctos?
2. Diseño: ¿Esta función hace demasiadas cosas? ¿Hay una forma más simple? ¿Los nombres describen intención?
3. Oficio: ¿Hay tests? ¿El error handling es razonable? ¿Se va a entender en 6 meses?

La mayoría de los comentarios útiles caen en la lente 2. La lente 3 es donde se aprende oficio.

Cómo dar feedback sin pisar al autor

# Mal: imperativo disfrazado de sugerencia
"Deberías usar un Map acá"

# Bien: pregunta que invita a pensar
"¿Pensaste en usar un Map? Para esta cantidad de lookups podría mejorar la complejidad"

# Bien: afirmación de tu lectura, no del código
"A mí este nombre `processData` no me dice qué procesa. ¿Te parece `validateInvoice`?"

Tres reglas:

• Comentá el código, no a la persona. “Esto está mal” no; “este branch puede devolver null sin que lo sepamos” sí.
• Distinguí bloqueantes de sugerencias. Un PR puede mergear con 5 sugerencias sin responder. No puede mergear con 1 bloqueante sin resolver.
• Preguntá antes de exigir. “¿Por qué lo hiciste así?” abre una conversación. “Cambialo a X” la cierra, a veces de manera injusta.

Tamaño de PR: la decisión que más impacta

El predictor #1 de velocidad de code review es el tamaño del PR:

• Menos de 200 líneas: review en 15 minutos, comentarios de diseño.
• 200–500 líneas: review en 30–45 minutos, comentarios puntuales.
• 500–1000 líneas: review en 1+ hora, fatiga, comentarios superficiales.
• Más de 1000 líneas: nadie lo lee, todos lo aprueban para sacárselo de encima.

Si tu PR se acerca a 500 líneas, probablemente estás haciendo dos cosas. Partilo. Si no podés partirlo, agregale un doc explicativo al inicio que cuente la historia.

La regla del “respondo en 24h”

Un PR que queda esperando más de 24 horas es una de las mayores fuentes de frustración en equipos. No necesitás leerlo en detalle: basta con decir “lo agarro mañana a primera hora”. La promesa cumple.

Lo que NO se comenta en code review

• Estilo que el linter arregla. Configurá ESLint, Prettier o Biome y dejá que el linter haga su trabajo.
• Decisiones de arquitectura que ya se tomaron en otro lado. Si el equipo ya eligió Postgres, no reabras esa discusión en cada PR de migración.
• Tu opinión personal sobre nombres obvios. A veces un nombre no es excelente, pero es razonable. No bloquees por eso.

Lo que SÍ se comenta:

• Funciones con efectos secundarios no obvios.
• Validación de input que falta.
• Tests que no cubren el camino triste (el del error, no el del éxito).
• Cambios que rompen compatibilidad sin documentarlo en el CHANGELOG.

El mejor code review no es el que encuentra más bugs. Es el que hace que el próximo PR del autor sea un poquito mejor.

El code review es una habilidad que se aprende haciendo. La primera vez que alguien te apruebe un PR diciendo “gracias, aprendí algo con tu comentario”, entendés de qué se trata.