Code reviews sin egos: qué buscamos y cómo revisamos código

En el artículo anterior contamos cómo trabajamos con ramas y Pull Requests: cada tarea vive en su rama y entra a main por un PR. Pero un Pull Request no se aprueba solo. Entre que alguien lo abre y que se mergea hay un paso que, hecho bien, es uno de los que más calidad agrega al producto: la revisión de código —el code review.

La idea es simple: antes de que un cambio toque la rama principal, otra persona lo lee. No para buscar culpables ni para lucirse, sino para atrapar lo que al autor se le pasó —a todos se nos pasa algo— y para que el conocimiento no quede encerrado en una sola cabeza. Pero hacerlo bien tiene su técnica, y hacerlo mal es una fuente clásica de fricción en los equipos. En este artículo explicamos cómo lo abordamos.

Un code review no es un examen que el autor aprueba o reprueba. Es una conversación entre dos personas que quieren lo mismo: que el código sea bueno.

Para qué sirve de verdad un code review

Es fácil pensar que revisar código sirve solo para “encontrar bugs”. Atrapa bugs, sí, pero ese es apenas uno de sus beneficios. Las razones por las que insistimos en revisarlo todo son varias:

• Atrapar problemas antes de producción. Un segundo par de ojos ve lo que el autor, demasiado cerca de su propio código, ya no distingue.
• Difundir el conocimiento. Cuando dos personas conocen una parte del sistema, no hay un único punto de falla. Si mañana alguien está de vacaciones, el proyecto no se detiene.
• Mantener un estándar común. Las revisiones son donde el equipo se pone de acuerdo, en la práctica, sobre cómo se escribe el código aquí. Con el tiempo, todo el repositorio se siente coherente.
• Mejorar a todos. Quien recibe el feedback aprende, pero quien revisa también: leer código ajeno es una de las mejores maneras de crecer como desarrollador.

Visto así, el code review deja de ser un trámite molesto antes del merge y se vuelve una de las herramientas más baratas que tiene un equipo para mejorar.

Qué buscamos al revisar

Cuando abrimos un Pull Request para revisarlo, no leemos línea por línea de arriba a abajo sin un plan. Tenemos una jerarquía mental: hay cosas que importan mucho y cosas que importan poco, y conviene no confundirlas. De lo más importante a lo menos:

1. ¿Hace lo que debe hacer?

Lo primero, y lo más importante: ¿el cambio resuelve el problema que dice resolver? Antes de mirar el estilo de una sola línea, entendemos la intención del PR —para eso sirve una buena descripción— y verificamos que el código realmente la cumpla. Un código bellísimo que resuelve el problema equivocado no sirve de nada.

2. Casos borde y manejo de errores

Aquí es donde se atrapan la mayoría de los bugs. El “camino feliz” suele estar bien; lo que se olvida son los bordes:

• ¿Qué pasa si la lista llega vacía? ¿Si el valor es null?
• ¿Y si la llamada a la red falla, o se va el internet a la mitad?
• ¿Hay números que podrían ser negativos, cero, o enormes?
• ¿Dos usuarios haciendo lo mismo al mismo tiempo rompen algo?

La pregunta que más repetimos en los comentarios es, justamente, “¿qué pasa si…?“.

3. Legibilidad y mantenibilidad

El código se escribe una vez y se lee decenas. Por eso pesa tanto que sea claro: nombres que dicen qué hacen las cosas, funciones que hacen una sola cosa, y nada de complejidad innecesaria. Una buena pregunta de revisor es: “¿entendería esto dentro de seis meses, sin que nadie me lo explique?”. Si la respuesta es no, vale la pena un comentario.

4. Pruebas

Un cambio de lógica debería venir acompañado de pruebas que lo respalden —y, sobre todo, que cubran esos casos borde del punto 2. Revisamos que las pruebas existan, que prueben lo que importa (no solo el camino feliz) y que efectivamente fallarían si el código se rompiera. Pruebas que pasan siempre, hagas lo que hagas, dan una falsa sensación de seguridad.

5. Seguridad

Algunas cosas merecen atención extra porque equivocarse sale caro: datos de usuarios que entran sin validarse, consultas a base de datos armadas concatenando texto (hola, inyección SQL), secretos o contraseñas que se cuelan en el código, permisos que no se verifican. No hace falta ser un experto en seguridad para detectar los descuidos más comunes; hace falta tenerlos presentes en cada revisión.

6. Lo que importa menos

Al final de la lista está el estilo: espacios, comillas, orden de los imports, comas. Importa, pero no debería ocupar el tiempo de una persona. Por eso lo dejamos casi por completo en manos de herramientas automáticas —linters y formatters— que corren solas en cada PR. Discutir formato a mano en los comentarios es gastar atención humana en algo que una máquina resuelve mejor y sin discusiones.

Las buenas prácticas: del lado de quien revisa

Saber qué buscar es la mitad. La otra mitad es cómo comunicarlo, porque un buen hallazgo dicho de mala forma genera más daño que beneficio. Estas son las reglas que seguimos como revisores:

• Sé amable. Se revisa el código, no a la persona. “Esta función hace demasiadas cosas” en lugar de “complicaste esto sin necesidad”. El objetivo es mejorar el código, no señalar a nadie.
• Explica el porqué. Un comentario que solo dice “cambia esto” obliga al autor a adivinar. “Cambiaría esto por X, porque así evitamos recalcularlo en cada iteración” enseña y convence.
• Distingue lo obligatorio de lo opcional. No todo tiene el mismo peso. Marcamos las sugerencias menores con algo como “nit:” (de nitpick, una nimiedad), para que quede claro qué bloquea el merge y qué es solo una idea que el autor puede tomar o dejar.
• Haz preguntas en lugar de dar órdenes. “¿Consideraste qué pasa si esto llega vacío?” abre una conversación; “esto está mal” la cierra. Y a veces la respuesta del autor te muestra que quien no había entendido el contexto eras tú.
• Reconoce lo bueno. Si una solución es elegante, dilo. El feedback positivo no es relleno: enseña tanto como el correctivo, y hace que recibir críticas en el mismo PR sea mucho más llevadero.
• Revisa a tiempo. Un PR que espera dos días bloquea a quien lo escribió y acumula conflictos. Tratamos las revisiones como una prioridad, no como algo que se hace “cuando haya un rato”.

Las buenas prácticas: del lado de quien escribe el PR

La calidad de una revisión también depende de lo que recibe el revisor. Quien abre el Pull Request puede hacer que revisarlo sea fácil o un suplicio:

• PRs pequeños. Es la regla de oro. Revisar 50 líneas se hace bien y con gusto; revisar 2.000 hace que el revisor se rinda y apruebe con un vistazo superficial —justo lo contrario de lo que queremos. Si una tarea es grande, se parte en varios PRs.
• Una descripción que explique el qué y el porqué. El revisor no estuvo en tu cabeza. Un par de líneas sobre qué cambia, por qué, y cómo probarlo ahorran muchísimo ida y vuelta.
• Revísalo tú primero. Antes de pedir revisión, lee tu propio diff completo. Te sorprenderá cuántos console.log olvidados, comentarios de prueba y descuidos atrapas tú mismo —y que ya no le harán perder el tiempo a nadie más.
• No te lo tomes personal. Los comentarios son sobre el código, no sobre ti. Recibir feedback sin ponerse a la defensiva es una habilidad, y vale oro.

Y cuando el revisor es un agente de IA

Cada vez más, una primera pasada de la revisión la hace un agente de IA: lee el diff, comenta posibles bugs, sugiere mejoras y a veces hasta propone el arreglo. Es una herramienta enormemente útil —no se cansa, no tiene prisa, no se salta archivos— y la usamos. Pero conviene tener clarísimo qué hace bien y dónde no se le puede creer a ciegas.

Un agente es excelente para el trabajo mecánico y de patrón, eso en lo que la atención humana se agota rápido:

• Detectar descuidos repetitivos: un null sin manejar, una variable sin usar, un catch vacío, un patrón que se repite mal copiado.
• Señalar casos borde que no se contemplaron: justo las preguntas “¿qué pasa si…?” que cuestan disciplina mantener.
• Sugerir nombres más claros y simplificaciones de código enredado.
• Recordar buenas prácticas y olores comunes de seguridad o rendimiento.

Donde hay que poner el freno es en confiar en su veredicto. Que un agente diga “todo se ve bien” no significa que esté bien — significa que no encontró nada que reconociera como un problema, que es muy distinto. Estos son los límites que tenemos siempre presentes:

• No conoce la intención real del cambio. El agente ve el código, no el ticket, ni la conversación con el cliente, ni la decisión de producto detrás. Puede aprobar algo impecable que resuelve el problema equivocado.
• Le falta el contexto del sistema completo. Una función puede verse perfecta en aislamiento y romper algo a tres módulos de distancia. El agente rara vez tiene todo el repositorio en la cabeza.
• Alucina con seguridad. A veces inventa un problema que no existe, o —peor— afirma que algo es correcto con total confianza cuando no lo es. El tono seguro no es evidencia.
• No juzga lo que importa de verdad. Decisiones de arquitectura, trade-offs de producto, si esta es la forma correcta de resolverlo a largo plazo: eso sigue siendo territorio humano.

Por eso, aunque el agente diga que está todo bien, hay cosas que confirmamos a mano antes de aprobar:

• Que realmente haga lo que el ticket pide. Esto se verifica contra la intención, no contra el código. Ningún agente lo sustituye.
• Que las pruebas existan, sean reales y pasen. Si el agente “confirma” que el código funciona, lo comprobamos corriendo las pruebas y la aplicación —no nos quedamos con su palabra.
• El código que el propio agente escribió o modificó. Si sugirió un arreglo y se aplicó, ese cambio se revisa con el mismo rigor que cualquier otro. Un agente revisando su propio código no es una segunda opinión.
• Cualquier cosa sensible: seguridad, manejo de datos de usuarios, dinero, permisos. Aquí el costo de equivocarse es alto, así que un humano mira siempre, pase lo que pase el agente.

La regla mental es sencilla: el agente es un revisor más, no el que firma. Su trabajo acelera y mejora la revisión humana, no la reemplaza. Cuando un agente y una persona revisan juntos, se atrapa mucho más que con cualquiera de los dos por separado — siempre que la persona siga siendo quien decide.

Confía en el agente para encontrar; confía en el humano para aprobar. Un “se ve bien” automático es un punto de partida, nunca el punto final.

Cómo lo hacemos en Nextik

Juntando todo lo anterior, nuestro flujo de revisión se ve así:

1. Todo entra a main por un Pull Request revisado. Sin excepciones, también para los cambios pequeños: los descuidos se cuelan justo cuando uno piensa “esto es trivial, no hace falta revisarlo”.
2. Las máquinas revisan primero. En cada PR corren solos el linter, el formatter y las pruebas automatizadas, y un agente de IA hace una primera pasada del diff. Si algo de eso falla, ni siquiera empezamos la revisión humana: para qué gastar atención de una persona en lo que una herramienta ya señaló.
3. Una persona revisa con la jerarquía de arriba. Primero lo importante —que funcione, los casos borde, la claridad— y el estilo se deja en manos de las herramientas. El revisor toma lo que haya levantado el agente como pistas, no como veredicto: confirma a mano lo que importa y deja comentarios concretos, marcando qué bloquea y qué es opcional.
4. Se conversa. El autor responde, ajusta lo que haya que ajustar o explica por qué lo hizo así. Si un comentario abre una duda razonable, se habla —en el PR o en cinco minutos de voz, lo que sea más rápido.
5. Se aprueba y se mergea. Cuando el revisor da el visto bueno y todo está verde, el PR entra a main y la rama se borra. Cierra el ciclo que describimos en el artículo de Git.

Hay un detalle de cultura que para nosotros es tan importante como el proceso: un comentario en un review no es un ataque, y una aprobación no es un favor. Es la forma normal en que un equipo construye software del que se siente orgulloso. Cuando esa idea se asienta, el code review deja de dar pereza y se vuelve, sinceramente, una de las mejores partes del día.

En resumen

Un buen code review no se trata de cazar errores ni de imponer gustos, sino de cuidar el producto y al equipo a la vez:

• Revisa con prioridades: primero que funcione y los casos borde; el estilo, déjaselo a las herramientas.
• Sé amable, explica el porqué y distingue lo que bloquea de lo que es opcional.
• Del lado del autor: PRs pequeños, buena descripción y una autorevisión antes de pedir ayuda.
• Reconoce lo bueno, no solo lo que falta.
• Y recuerda lo esencial: se revisa el código, nunca a la persona.

Son hábitos sencillos, pero su efecto se acumula. Un equipo que revisa bien su código no solo tiene menos bugs en producción: tiene gente que aprende más rápido, un repositorio coherente y la tranquilidad de que nada importante llega a main sin que más de una persona lo haya mirado a los ojos.