Code Reviews que no destruyen a tu equipo

⏱️ Tiempo de lectura: 7 minutos

¿Alguna vez abriste un PR y sentiste que te estaban juzgando a ti, no a tu código? Ese comentario de "esto está mal" sin más contexto, ese tono que suena más a interrogatorio que a colaboración. Si lo viviste, sabes exactamente de qué hablo.

Las code reviews son probablemente la herramienta más poderosa y más mal usada del desarrollo de software. Bien hechas, aceleran el aprendizaje, distribuyen conocimiento y mejoran la calidad del código de todo el equipo. Mal hechas, generan ansiedad, fricción y devs que prefieren no pedir revisión por miedo al escarnio público.

Llevo más de una década haciendo y recibiendo reviews. He visto los dos extremos. Y lo que aprendí es que el problema casi nunca es técnico: es de comunicación.

Por qué las code reviews fallan antes de empezar

Hay un error de base que comete mucha gente: entrar a una review con mentalidad de auditor. Como si tu trabajo fuera encontrar todo lo que está mal. Eso no es una review, es una cacería.

El punto de una code review no es demostrar que sabes más que quien escribió el código. Es asegurarte de que el código que entra al repositorio es correcto, mantenible y entendible por el resto del equipo. Esa distinción parece obvia, pero cambia completamente cómo escribes los comentarios.

Algo que me pasó hace años: un dev senior en mi equipo dejaba comentarios como "¿en serio hiciste esto así?" o "reescribe todo esto". Sin explicación. Sin alternativa. El resultado fue que los devs más junior dejaron de subir PRs pequeños y frecuentes, y empezaron a acumular cambios enormes para "evitar reviews". El problema que intentaba resolver (calidad del código) empeoró por cómo lo estaba abordando.

El lenguaje importa más de lo que crees

Hay una diferencia enorme entre estos dos comentarios:

"Esto está mal."

"Ojo que si el array viene vacío, esta función va a lanzar una excepción. ¿Qué te parece agregar una validación al inicio?"

El segundo dice exactamente lo mismo en términos técnicos, pero hace tres cosas que el primero no hace: explica el problema, muestra el impacto y propone una solución (o al menos abre la conversación).

Algo que me ha funcionado es usar prefijos para dejar claro el peso de cada comentario. No todos los comentarios son igual de críticos, y quien recibe la review necesita saber cuáles son bloqueantes y cuáles son sugerencias:

[bloqueante] — esto necesita resolverse antes de mergear. [sugerencia] — me parece que podría mejorarse, pero tú decides. [pregunta] — no entiendo del todo el contexto, ¿me explicas? [nit] — detalle menor, cuestión de estilo, puede ignorarse.

Este sistema simple reduce el 80% de la ambigüedad en las reviews. La persona que recibe el feedback sabe exactamente qué es urgente y qué es opcional. Y quien hace la review se obliga a pensar dos veces antes de escalar algo a bloqueante.

Revisar código ajeno sin perder la humildad

Aquí va algo que tardé en aprender: cuando no entiendes un fragmento de código, la primera reacción no debería ser "esto está mal escrito". Debería ser "¿qué me estoy perdiendo yo?"

A veces el código parece raro porque hay una restricción de negocio que no conoces. O porque hay un bug que ese dev ya encontró y está workaroundeando. O simplemente porque tiene más contexto que tú sobre esa parte del sistema.

Preguntar antes de sentenciar no es debilidad. Es inteligencia.

Cuando tú eres quien recibe la review

Recibir feedback también tiene su arte. Y no, no es fácil desconectar el ego cuando alguien te dice que tu código podría estar mejor. Pero hay una mentalidad que ayuda muchísimo: el código no eres tú.

Tú escribiste ese código en un contexto específico, con la información que tenías en ese momento. Si alguien encuentra una forma mejor, eso no significa que eres mal dev. Significa que tienes un colega que sabe algo que tú todavía no sabías.

Dicho esto, no toda crítica es válida. Si recibes un comentario que no entiendes o con el que no estás de acuerdo, defiende tu postura con argumentos. Las reviews son una conversación, no una sentencia. He visto reviews donde el autor del código terminó convenciendo al reviewer de que su enfoque era correcto. Eso también es parte del proceso.

Reviews como herramienta de mentoring (y no al revés)

Si eres senior o tech lead, tus reviews son probablemente la herramienta de mentoring más subestimada que tienes. Cada comentario que dejas es una oportunidad de enseñar algo, no solo de corregir.

En lugar de decir "usa un map aquí", puedes decir "un map aquí haría esto más legible porque evita el estado mutable del loop. Si quieres, te comparto un artículo sobre programación funcional que lo explica bien". Mismo tiempo, impacto completamente diferente.

Ahora bien, esto no significa que tengas que escribir una tesis en cada comentario. A veces "extrae esto a una función" es suficiente. El punto es calibrar: para cambios triviales, ve al grano. Para patrones que el dev probablemente va a repetir, invierte un poco más.

El problema de las reviews que nunca terminan

Hay un antipatrón que destruye la velocidad de los equipos: el ciclo infinito de revisión. PR abierto, comentarios, cambios, más comentarios, más cambios, y a la semana todavía no mergeó nada.

Esto pasa cuando no hay criterios claros de aprobación, cuando los reviewers agregan nuevos comentarios en cada ronda, o cuando se mezclan discusiones de estilo con problemas reales.

Algo que funciona bien es separar lo que bloquea el merge de lo que puede resolverse después en un ticket separado. El perfeccionismo en reviews tiene un costo real: código que tarda semanas en llegar a producción, devs frustrados y momentum perdido.

Antes de irte

Si sientes que en tu equipo las reviews son más una fuente de tensión que de aprendizaje, probablemente no eres el único que lo piensa. Cambiar esa dinámica lleva tiempo, y no siempre depende solo de ti. A veces hay patrones culturales arraigados que no se cambian con un solo PR bien comentado.

Empieza por lo que sí puedes controlar: la próxima review que hagas, agrega un prefijo a tus comentarios y explica el porqué de al menos uno. Es un cambio pequeño, pero los cambios pequeños y consistentes son los que terminan moviendo la aguja.