El Code Review que Nadie Hace Bien
La mayoría de los code reviews que he visto siguen el mismo guión: alguien abre un PR, un compañero escanea en busca de bugs obvios, deja algunos comentarios de nitpick sobre nombres de variables, aprueba y sigue adelante. Quizás quince minutos de atención, quizás menos. A producción.
Eso no es un code review. Es un corrector ortográfico con pasos adicionales.
Los mejores reviews en los que he participado — como autor y como revisor — han cambiado cómo pienso sobre un problema. Han sacado a la luz una falla de diseño antes de que se volviera carga estructural. Me han enseñado una API que no sabía que existía. Han iniciado conversaciones que terminaron remodelando el feature completo.
La brecha entre esas dos experiencias es enorme, y casi nadie habla de ella.
Lo que la Mayoría de los Reviews Realmente Optimizan
Detección de bugs. Eso es lo que la mayoría de los equipos cree que son los code reviews. Atrapar el error de índice, detectar el null check faltante, señalar el riesgo de inyección SQL.
Esas cosas importan y deberías detectarlas. Pero si la detección de bugs es tu objetivo principal, ya cometiste un error — porque los bugs son lo más barato de encontrar en un code review. El análisis estático, los tests y los type checkers atrapa la mayoría antes de que ningún humano vea el código. Lo que las herramientas automatizadas no pueden detectar es exactamente en lo que los reviews deberían enfocarse.
Diseño. Legibilidad. Transferencia de conocimiento. Consistencia con cómo el resto del equipo piensa y construye.
Estas cosas son difíciles de automatizar y difíciles de recuperar una vez que se mergean y otras cosas se construyen encima.
TIPAntes de abrir el diff, lee la descripción del PR. Si no hay descripción — o si solo dice “corrige bug” — pide una. El contexto detrás de un cambio suele ser más importante que el cambio en sí.
Las Tres Capas de un Buen Review
Pienso en los code reviews en tres capas, de la superficie a lo profundo:
Capa 1 — Corrección. ¿Este código hace lo que dice que hace? ¿Hay casos borde que el autor pasó por alto? ¿El manejo de errores es razonable? Esta es la capa en la que la mayoría de los revisores pasan todo su tiempo.
Capa 2 — Diseño. ¿Es esta la forma correcta de resolver el problema? ¿Una abstracción diferente haría los cambios futuros más fáciles? ¿Esto agrega complejidad que se va a componer? ¿Encaja con cómo está estructurado el resto del sistema? Aquí es donde está el verdadero apalancamiento, y donde la mayoría de los reviews se quedan cortos.
Capa 3 — Transferencia de conocimiento. ¿Cada miembro del equipo entiende este cambio lo suficientemente bien como para ser responsable de él? Si el autor desapareciera mañana, ¿podría alguien más depurarlo, extenderlo, eliminarlo de forma segura? Si la respuesta es no, el review no está terminado.
La mayoría de los reviews solo ocurren en la Capa 1. Los buenos llegan a la Capa 2. Los mejores tratan la Capa 3 como un requisito.
Cómo Dejar Comentarios Realmente Útiles
Hay un arte en dejar comentarios de review que mejoran el código sin desmoralizar al autor ni crear intercambios interminables.
El enfoque más útil que he encontrado es separar las preguntas de las sugerencias de los blockers.
Una pregunta es algo que no entiendes: “¿Por qué elegimos hacer X aquí en lugar de Y?” Invita a una explicación y a menudo o te enseña algo o hace que el autor se dé cuenta de que debe repensar.
Una sugerencia es opcional: “Me pregunto si podríamos simplificar esto haciendo Z — pero funciona como está.” Sin presión, solo pensando en voz alta.
Un blocker es algo que necesita cambiar antes de que esto se lance: “Esto va a romperse si la lista está vacía — necesitamos manejar ese caso.”
Cuando los mezclas — cuando todo parece un comentario igualmente urgente — los autores no saben qué priorizar y los revisores sienten que hicieron un trabajo exhaustivo cuando solo hicieron nitpicking.
TIPEtiqueta tus comentarios explícitamente:
[pregunta],[nit],[sugerencia],[blocker]. Suena formal, pero hace la conversación dramáticamente más rápida.
El PR que Es Demasiado Grande para Revisar
Hay una forma de deuda técnica que vive enteramente en tu proceso de PRs: el pull request enorme que nadie puede revisar razonablemente.
Quinientas líneas en quince archivos. Cambios a la capa de datos, la API, la interfaz y el suite de tests todos en una sola rama. Para cuando has leído todo, ya perdiste el hilo del primer archivo.
Estos PRs se aprueban sin una revisión real porque la revisión real no es humanamente posible a esa escala. Luego se mergean, y todos aprenden nada, y las decisiones de diseño que están baked into esas quinientas líneas se vuelven la fundación incuestionable sobre la que todo lo demás se construye.
Si tus PRs regularmente superan las 300-400 líneas, el problema no son tus revisores — es tu flujo de trabajo. Divide el trabajo en unidades más pequeñas y revisables. Eso fuerza un mejor diseño, hace que la conversación del review sea más precisa, y significa que los merges ocurren más rápido porque el radio de impacto de cualquier cambio es menor.
Los Reviews como Construcción de Equipo
La mejor cultura de code review que he experimentado fue en un equipo donde se esperaba que los revisores dijeran qué aprendieron del PR, no solo qué encontraron mal.
Ese pequeño cambio transformó todo. Significó que el autor escribía más contexto. Que el revisor se involucraba más profundamente. Que la conversación en el PR se convirtió en un registro de cómo evolucionó el pensamiento del equipo — no solo una lista de correcciones.
Los code reviews son el momento de mayor apalancamiento que tienes para construir estándares compartidos. No la documentación, no las reuniones de arquitectura — la conversación línea por línea sobre cómo construyen cosas juntos.
La mayoría de los equipos usa ese momento para marcar una casilla. Los mejores lo usan para crecer.
No necesitas una reforma del proceso para mejorar tus code reviews. Necesitas revisores que se presenten con genuina curiosidad en lugar de una checklist, autores que escriban contexto en vez de solo código, y un entendimiento compartido de que el objetivo es un mejor codebase — no solo un PR mergeado.
La diferencia entre un buen review y uno excelente son quince minutos de pensamiento real. Casi siempre vale la pena.