Repensando el pull request¶

8 minutos de lectura · 28 abril 2026

Llevo años revisando pull requests como si revisar fuera encontrar errores. Cada uno terminaba con una lista de comentarios y la sensación de haber sido útil.

El problema es que esa sensación es muy mala señal de utilidad real.

Este año empecé a hacer code reviews de otra forma. Tres cambios pequeños, un cambio grande de mentalidad.

El cambio de mentalidad¶

Antes pensaba: "mi trabajo es que este PR no rompa nada". Ahora pienso: "mi trabajo es que la siguiente persona que toque este código pueda entenderlo".

Suena parecido. No lo es. El primero te lleva a leer línea a línea buscando defectos. El segundo te lleva a leer el diff entero como si fuera un texto: ¿se entiende el porqué? ¿queda claro qué hace? ¿qué decisiones se tomaron y por qué?

El 90% de los defectos puntuales los caza el linter, el type checker o los tests. El 100% de las decisiones mal documentadas se mantienen como deuda hasta que alguien se cruza con ellas a las dos de la mañana.

Los tres cambios prácticos¶

1. Empezar por leer la descripción¶

Suena obvio. No lo hacía. Iba directo al Files changed.

Ahora empiezo por el cuerpo del PR. Si la descripción no me dice qué problema resuelve y por qué este enfoque, ese es el primer comentario. No reviso código hasta que esto está claro.

Beneficio secundario: el autor mejora sus descripciones después de un par de iteraciones. La calidad del histórico del proyecto sube.

2. Distinguir tres tipos de comentario¶

Cada comentario lleva ahora un prefijo, robado a Google internamente:

• nit: — preferencia, no bloqueante. "Yo lo nombraría así".
• question: — no sé si esto es un bug o yo no entiendo. Pregunta de verdad.
• blocker: — esto tiene que cambiar antes de merge. Y explico por qué.

Sin el prefijo, todo comentario se lee como una orden. El autor pierde dos horas atendiendo nits porque no sabe que puede ignorarlos. Con el prefijo, el contrato es explícito.

3. Aprobar con condiciones¶

Antes solo aprobaba cuando todo me parecía bien. Lo que pasaba: el PR esperaba mi siguiente revisión por dos comentarios menores.

Ahora apruebo en el momento si los blocker: están resueltos, aunque queden nit: o question:. El autor decide. Mi review no es el cuello de botella del merge.

El cambio más caro: revisar menos¶

Antes revisaba todos los PRs del equipo. Sentía que tenía que. Era el ingeniero senior, era mi responsabilidad.

Resultado real: bottleneck, gente esperando, y revisiones cada vez más superficiales porque no daba tiempo.

Ahora reviso solo cuando:

• El PR toca un área que conozco mejor que el resto.
• El autor lo pide explícitamente.
• Hay decisiones de diseño que afectan más allá del PR.

Para el resto, el código es del equipo. Que se revisen entre ellos. Mi trabajo es haberles dado el contexto suficiente para que esa revisión sea buena.

Métrica que me importa ahora¶

No es "PRs revisados por semana". Es "tiempo medio entre que se abre un PR y se mergea".

Si ese número baja sin que la calidad caiga, algo está funcionando. Si sube, hay un cuello de botella que arreglar —y muchas veces ese cuello de botella era yo.

¿Comentarios o correcciones? info@encodigo.es.