Code review hecho mal arruina la productividad del equipo

Vamos al grano: si en tu equipo el code review se resume a buscar bugs y señalar errores de sintaxis, están desperdiciando una de las mejores oportunidades de crecimiento que tienen como desarrolladores.

El problema no es que hagan code review. El problema es cómo lo hacen.

La realidad es que la mayoría de equipos trata el code review como un checkpoint obligatorio antes de hacer merge. Una especie de QA manual donde el objetivo es encontrar todo lo que está mal. Y acá es donde se pudre todo.

Por qué el enfoque tradicional no funciona

Cuando el code review se convierte en una cacería de bugs, pasan cosas feas:

El desarrollador que recibe el review se pone a la defensiva. Es natural. Nadie quiere que le marquen 15 cosas "mal hechas" en su código. El feedback se siente como crítica personal, no como ayuda técnica.

Los reviewers se enfocan en detalles menores. Es más fácil marcar un espacio de más o un nombre de variable poco claro que entender si la arquitectura tiene sentido. Resultado: reviews llenos de comentarios irrelevantes.

Se genera un cuello de botella. Si el review se percibe como "encontrar problemas", el proceso se alarga. Los developers senior se vuelven más exigentes, los juniors más lentos para aprobar por miedo a que se les escape algo.

El conocimiento no se comparte. Cuando el foco está en "¿qué está mal?", perdés la oportunidad de explicar "¿por qué esto podría ser mejor?" o "¿conocés esta alternativa?".

El verdadero propósito del code review

El code review no es para encontrar bugs. Para eso tenés tests, linters y herramientas de análisis estático. El code review tiene dos objetivos reales:

1. Compartir conocimiento

Es la forma más natural de que el equipo aprenda junto. El senior puede mostrar patrones útiles, el junior puede aportar perspectivas frescas, alguien con experiencia en cierta tecnología puede explicar buenas prácticas específicas.

2. Mantener consistencia

No se trata de imponer un estilo único y rígido, sino de que el código del equipo tenga cierta coherencia. Que cuando alguien abra un archivo, pueda entender rápido cómo está estructurado porque sigue convenciones similares al resto del proyecto.

Cómo hacer code review que sume

Cambiar el mindset

Antes de tocar herramientas o procesos, hay que cambiar la mentalidad. El code review no es un examen. Es una conversación técnica entre colegas que quieren mejorar juntos.

Para el que hace el review: tu trabajo no es encontrar errores. Es entender qué hizo tu compañero y ayudarlo a mejorarlo si ves oportunidades.

Para el que recibe el review: no es una crítica a tu capacidad como developer. Es input valioso de alguien que tiene otra perspectiva sobre el mismo problema.

Enfocarse en lo que importa

En lugar de marcar cada detalle sintáctico (para eso está el linter), concentrate en:

• Claridad: ¿El código es fácil de entender? ¿Los nombres son descriptivos?
• Arquitectura: ¿La solución tiene sentido? ¿Hay una forma más simple?
• Mantenibilidad: ¿Va a ser fácil modificar esto en el futuro?
• Aprendizaje: ¿Hay algo que puedas enseñar o aprender?

Usar un lenguaje constructivo

La diferencia entre un buen review y uno tóxico está en cómo comunicás el feedback.

En lugar de: "Esto está mal" Decí: "¿Consideraste usar X acá? Podría ser más claro"

En lugar de: "Este código es confuso" Decí: "Me cuesta seguir la lógica acá. ¿Podés explicarme la idea?"

En lugar de: "No hagas esto" Decí: "En mi experiencia, Y suele funcionar mejor que X porque..."

Implementar un proceso claro

Antes del review

• Self-review primero. El autor debería revisar su propio código antes de pedir review. Elimina muchos errores básicos.
• PRs chicos. Es mejor hacer reviews frecuentes de cambios pequeños que reviews gigantes una vez por semana.
• Contexto claro. La descripción del PR tiene que explicar qué se cambió y por qué.

Durante el review

• Marcar lo positivo. Si ves algo bien hecho, comentalo. "Me gusta cómo resolviste esto" o "Buena elección usar X acá".
• Explicar el por qué. No alcanza con decir "cambiar esto". Explicá la razón detrás de la sugerencia.
• Diferenciar niveles. ¿Es un "debe cambiar" o un "podría ser mejor"? Dejalo claro.

Después del review

• Conversación, no ping-pong. Si hay desacuerdo, hablen. No se pasen 10 comentarios de ida y vuelta.
• Aprobar cuando corresponde. Si los cambios solicitados están hechos, aprobá. No hagas esperar por detalles menores.

Herramientas que ayudan

Automatizar lo automatable

// .eslintrc.json
{
  "extends": ["eslint:recommended"],
  "rules": {
    "no-unused-vars": "error",
    "no-console": "warn",
    "prefer-const": "error"
  }
}

Si tenés un linter configurado, no pierdas tiempo en el review marcando que falta un punto y coma. Concentrate en cosas que las herramientas no pueden detectar.

Templates de PR

Un template simple ayuda a dar contexto:

## ¿Qué cambié?

## ¿Por qué?

## ¿Cómo testeé?

## Notas para el reviewer

Checklists para reviewers

Tener una lista mental (o literal) ayuda a mantenerse enfocado:

• ¿El código hace lo que dice que hace?
• ¿Es fácil de entender?
• ¿Hay casos edge que no se consideraron?
• ¿Los tests cubren la funcionalidad nueva?
• ¿Hay oportunidades de refactor o mejora?

Métricas que importan

Si querés medir si el code review está funcionando, no mires cuántos bugs encontraron. Mirá:

• Tiempo promedio de review: ¿Se está alargando mucho el proceso?
• Cantidad de ida y vuelta: ¿Los PRs necesitan muchas rondas de cambios?
• Participación del equipo: ¿Todos están haciendo y recibiendo reviews?
• Knowledge sharing: ¿El equipo está aprendiendo cosas nuevas en los reviews?

Casos especiales

Reviews de desarrolladores junior

Los juniors necesitan más contexto y paciencia. En lugar de solo marcar qué cambiar, explicá:

• Por qué esa solución es mejor
• Qué patrones están usando
• Dónde pueden aprender más sobre el tema

Reviews de refactors grandes

Cuando alguien refactoriza mucho código:

• Revisá por partes si es posible
• Enfocate en la arquitectura general antes que en detalles
• Asegurate de que los tests pasen y cubran lo necesario

Reviews de features críticas

Para funcionalidades importantes:

• Involucrá a más de un reviewer
• Prestá especial atención a edge cases
• Considerá hacer pair programming en lugar de review asíncrono

El code review no es opcional

Algunos equipos caen en la trampa de saltear el code review "porque hay que entregar rápido" o "porque es un cambio chiquito". Error.

El code review es una inversión. Te puede hacer más lento a corto plazo, pero te ahorra mucho tiempo a largo plazo. Bugs que no llegan a producción, código más consistente, equipo que aprende más rápido.

Preguntas frecuentes

¿Cuánto tiempo debería tomar un code review? Depende del tamaño del PR, pero en general no más de 30 minutos. Si necesitás más tiempo, probablemente el PR es muy grande.

¿Todos los cambios necesitan review? En equipos serios, sí. Incluso cambios chicos pueden tener consecuencias inesperadas o ser oportunidades de aprendizaje.

¿Qué hago si hay desacuerdo técnico en el review? Hablen, no escriban 20 comentarios. Si no llegan a acuerdo, que decida el tech lead o arquitecto del proyecto.