Como hacer code reviews efectivos sin bloquear al equipo

Un buen code review mejora el sistema. Un mal code review solo agrega friccion.

Problema comun

Equipos senior suelen caer en dos extremos:

• review superficial para “mover tickets”,
• review eterno con comentarios de preferencia personal.

Ninguno de los dos sirve.

Framework rapido (3 capas)

Capa 1: Correctitud y riesgo

• rompe flujo funcional?
• maneja errores reales?
• afecta seguridad o datos?

Capa 2: Mantenibilidad

• nombres y estructura claros?
• duplicacion innecesaria?
• deuda tecnica justificada?

Capa 3: Evolucion

• facilita cambios futuros?
• observabilidad suficiente?
• tests correctos para el riesgo del cambio?

Regla de oro

Comenta sobre impacto, no sobre ego.

En lugar de: “yo lo haria distinto”

Mejor: “esta decision aumenta complejidad accidental por X, propongo Y por Z”.

Plantilla practica para comentar PR

Usa un formato corto para que cada comentario tenga contexto, impacto y accion:

### [Bloqueante] Validacion de input ausente
- Contexto: `createUser()` guarda datos directos del request.
- Riesgo: podemos persistir email invalido y romper notificaciones.
- Sugerencia: validar formato antes de persistir.

```ts
if (!isValidEmail(payload.email)) {
  throw new BadRequestError("invalid email");
}
```

- Evidencia: el test `user-create-invalid-email` falla sin esta validacion.

Si no es bloqueante, marca claro el nivel de prioridad:

- [No bloqueante] renombrar `data` -> `userProfile` para legibilidad.
- [No bloqueante] extraer `buildResponse()` para reducir duplicacion.

SLA de review sugerido

• PR pequeno: < 24h
• PR mediano: < 48h
• PR grande: dividir en slices

La calidad no depende de tardar mas; depende de revisar con foco.

Template de descripcion de PR (para facilitar review)

## Que cambia
- Agrega endpoint `POST /users`.
- Agrega validacion de payload y tests de contrato.

## Riesgo
- Medio: toca flujo de registro.

## Como probar
1. `npm test -- user-create`
2. `curl -X POST /users ...` con payload valido e invalido.

## Rollback
- Revertir commit + redeploy.

Integracion con IA (sin perder criterio)

Puedes usar IA para pre-review y deteccion de patrones repetitivos, pero la decision final debe ser humana.

Relacionado:

• /blog/28-code-review-asistido-por-ia-que-si-y-que-no/
• /blog/20-understanding-story-points-agile-estimation/
• Hub Engineering Culture: /blog/category/engineering-culture/

Cierre

Review efectivo = mejor arquitectura + menos incidentes + mejor aprendizaje de equipo. Esa combinacion paga sola.