El objetivo del review de un Staff Engineer es el desarrollo del equipo. Encontrar bugs es la base del trabajo, y las herramientas ya atrapan parte de eso antes de que el PR se abra. Lo que separa este review de uno común es lo que escribes en el comentario y lo que eliges dejar pasar.

Cuatro anti-patterns que debilitan el review

Nitpick de estilo. Espaciado, comillas, orden de imports: tienes un linter y CI quejándose en cada push. El estándar de reviewer del Google Engineering Practices ubica estilo y convención automatizada por debajo de corrección y diseño. Un comentario de estilo gasta la atención del autor en lo que una herramienta resuelve sola.

Reescribir el código en el comentario. "Yo lo haría así:" seguido de veinte líneas impone tu solución y enseña a la persona a copiar. Un comentario con el problema y la restricción lleva al autor a producir su propia solución.

Aprobar sin leer. Un LGTM de treinta segundos protege el plazo y traslada el riesgo a producción. Decir "esta semana no puedo revisar" es más honesto y más rápido para quien espera.

Bloquear por gusto. "Esto viola nuestro patrón de manejo de errores" es un principio con una razón registrada en algún lado del equipo. "Prefiero Promises a async/await" es preferencia. El mismo documento de Google separa los dos y pide que un comentario bloqueante nombre un riesgo concreto o un acuerdo violado.

El comentario que transfiere razonamiento

Un comentario corto obliga al autor a adivinar el motivo. Un comentario con contexto devuelve el motivo junto con el pedido, y el siguiente lector del PR aprende el razonamiento también.

// débil
"Usa memoización acá"

// fuerte
"Este componente se re-renderiza en cada cambio de estado del padre, incluso
cuando la prop `items` no cambia. useMemo en ese cálculo evita re-renders
en listas grandes. Contexto: lo discutimos en la issue #847, pantalla de pedidos."

La versión fuerte entrega causa, efecto e historia. La guía de comentarios de Google pide eso: explicar el porqué y sugerir el camino, en lugar de señalar el defecto e irse.

Peso explícito de cada comentario

  • Bloqueante: frena el merge. Seguridad, corrección, contrato de API roto. Nombra el riesgo en la frase.
  • Sugerencia: recomienda y no traba. "Extraer esto a un helper dejaría el test más fácil, aunque inline también funciona."
  • Nit: opinión liviana, marcada con el prefijo nit: que adoptó la guía de Google. El autor la salta sin discusión.
  • Pregunta: quieres entender la decisión. "¿Por qué Map acá y no objeto literal? Quiero el mismo criterio en el módulo de billing."

La categoría al inicio de la frase elimina la mayor parte de los malentendidos. Un autor que recibe un "nit:" sabe que puede seguir sin responder.

Elogio que nombra lo que funcionó

Cuando el código trae una buena decisión, di cuál es. "Me gustó" no le dice nada al siguiente lector; "el discriminated union acá vuelve imposible representar estado inválido, voy a usar la misma idea en el módulo de pagos" enseña a dos ingenieros al mismo tiempo.

// "El discriminated union acá vuelve imposible representar estado inválido.
// Voy a usar la misma idea en el módulo de pagos."

Feedback específico en las dos direcciones convierte la cola de PRs en algo distinto a un corredor de obstáculos.

Cuando el hilo pasa de cuatro respuestas

Una discusión asíncrona con más de cuatro respuestas cuesta más que la llamada de quince minutos que la resuelve. Llama a la persona, alinea, y escribe la decisión en el PR para quien llegue después. El capítulo 9 de Software Engineering at Google trata el review como conversación de ingeniería y recomienda CL chicos justamente para que la discusión quepa en texto.

La arquitectura entra antes del código. Un design doc corto, comentable mientras cambiar es barato, evita el PR de ochocientas líneas que nadie puede revisar de verdad.

Lo que dejas pasar a propósito

Código que funciona, es mantenible y no rompe ningún principio recibe tu OK aunque sea distinto de lo que tú habrías escrito. Tú tienes contexto que el autor no tiene; el autor tiene contexto que tú no tienes. Bloquear PRs por encima de lo necesario le cuesta velocidad al equipo y devuelve poco.

El documento de Google sobre qué buscar en un review lista diseño, funcionalidad, complejidad, tests, nombres y comentarios en ese orden. Los bugs viven en funcionalidad; desarrollar al equipo vive en el comentario que escribes.

Referencias