Responder, discutir y cerrar comentarios sin trabarse
Un pull request que queda tres días en ida y vuelta casi nunca es un problema técnico. Cómo responder un comentario con el que no estás de acuerdo, cuándo la discusión se sale del hilo y qué hace que un cambio se destrabe.
Un cambio chico, cuatro comentarios, tres días abierto. Nadie está enojado ni nadie tiene razón de más: el hilo se trabó. Es el costo más frecuente de la review y casi nunca es un problema de código.
Lo que lo destraba es casi siempre lo mismo: decidir qué tipo de comentario es antes de responderlo, y mover a otro canal lo que no se resuelve escribiendo.
Los cuatro tipos de comentario
| Tipo | Qué pide | Cómo se cierra |
|---|---|---|
| Bloqueante | Está mal y no puede salir así | Se corrige o se muestra por qué no está mal |
| Sugerencia | Se podría mejorar | Se aplica, o se responde por qué no, y se sigue |
| Pregunta | No entiendo esto | Se contesta; si costó explicarlo, probablemente falte un nombre mejor |
| Comentario al pasar | Dato, contexto, algo para otro momento | Se acusa recibo y no frena nada |
Marcar el tipo al escribir ahorra la mitad de las idas y vueltas. Un “esto no puede salir así” etiquetado como tal se atiende; la misma frase sin etiquetar se lee como opinión y se discute.
Cuando no estás de acuerdo
No aplicar un comentario es legítimo. Lo que no funciona es aplicarlo en silencio estando en desacuerdo —el problema vuelve— ni discutir sin dar información nueva.
Cómo responder sin trabar
- Mostrar que entendiste. Repetir el punto en una línea evita la mitad de las discusiones, que son dos personas hablando de cosas distintas.
- Dar el dato que el otro no tenía. “Esto corre en el render inicial y ese servicio tarda 400 ms” cierra un hilo; “prefiero así” lo alarga.
- Ofrecer el costo. “Lo cambio, son diez minutos” o “esto implica tocar tres módulos más, ¿lo hacemos en un ticket aparte?”. Casi siempre la discusión era sobre alcance, no sobre diseño.
- Aceptar rápido lo barato. Si da igual y cambiarlo cuesta dos minutos, cambiarlo. Gastar veinte líneas en defender un nombre es peor negocio que aceptarlo.
Cerrar un hilo de verdad
Un comentario resuelto necesita dejar rastro de cómo se resolvió, no sólo marcarse como resuelto. La persona que revisó tiene que poder verificar sin releer todo el cambio.
Antes de seguir, predecí
Y cuando la respuesta es “tenés razón, pero no ahora”, el cierre honesto es un ticket con referencia al hilo. Un “lo dejamos para después” sin ticket es un no disfrazado, y todos en el equipo lo saben.
El factor que más pesa: los tiempos
Un cambio que espera revisión un día entero se vuelve caro por un motivo que no tiene que ver con la review: quien lo escribió ya se fue a otra cosa y tiene que reconstruir el contexto para responder.
Tres hábitos que destraban más que cualquier técnica de comunicación
- Pull requests chicos. Uno de cuarenta líneas se revisa a fondo; uno de mil se aprueba con comentarios cosméticos porque nadie puede sostener la atención.
- Revisar temprano en el día, antes de entrar en el trabajo propio. La review es trabajo del equipo, no un favor que se hace cuando sobra tiempo.
- Una sola ronda cuando se pueda. Juntar todos los comentarios de una vez, en vez de ir soltando uno por vez a medida que se lee.
Más a fondo · nivel seniorAprobar con comentarios
Aprobar dejando sugerencias no bloqueantes —“si te parece, cambiá el nombre; no hace falta que esperes otra ronda”— es de las herramientas más subestimadas. Transfiere la decisión a quien escribió el código, evita una vuelta completa y funciona en la enorme mayoría de los casos, que no son bloqueantes. Reservar el bloqueo para lo que efectivamente no puede salir es lo que le devuelve peso a la palabra.
El hilo que se puede trabar
Escenario · 1 decisión como mínimo
Te dejaron un comentario con el que no estás de acuerdo
Tu pull request tiene ocho comentarios. Siete son menores y uno dice: «esto debería cachearse, si no va a ser lento». Vos ya lo pensaste: ese cálculo corre una vez por sesión y cachearlo agrega invalidación. ¿Qué respondés?
El revisor responde: «igual me parece que conviene». Vas por la tercera respuesta y ninguno dijo nada nuevo.
DesenlaceSi en la segunda vuelta nadie aportó información que el otro no tuviera, el hilo escrito ya no va a resolverlo. Ahí conviene una llamada de cinco minutos, y volver a escribir la conclusión en el hilo para que quede.
Agregás el caché y la invalidación. Tres meses después, alguien reporta que ve datos viejos después de cambiar su perfil.
DesenlaceLa complejidad la pagó el equipo y la decisión no la tomó nadie. Aceptar rápido lo barato está bien —un nombre, un orden de parámetros—, pero esto no era barato, y la diferencia entre las dos cosas es justamente lo que hay que aprender a distinguir.
El revisor contesta que en producción esa sesión puede reabrirse muchas veces por día y que él vio ese endpoint lento en el panel. Ahora tenés vos información nueva.
El hilo llega a doce comentarios. El pull request lleva cuatro días abierto.
DesenlaceCuatro días de un pull request abierto cuestan más que casi cualquier decisión de diseño que se esté discutiendo: hay que rebasear, el contexto se enfría y otros esperan. El costo de tener razón tarde suele ser mayor que el de equivocarse rápido.
Sale el pull request y el ticket queda creado, sin dueño y sin fecha.
DesenlaceFunciona sólo si el ticket se mira de nuevo. Un «lo vemos después» sin dueño es la forma más común de cerrar un hilo sin cerrar nada, y a los seis meses el comentario original sigue teniendo razón.
Mirás el panel: el endpoint aparece entre los cinco más lentos. Cacheás, con invalidación al guardar el perfil, y lo respondés en el hilo.
DesenlaceCerrado en dos vueltas, con una decisión mejor que las dos posiciones iniciales. Y quedó escrito por qué, que es lo que va a evitar que dentro de un año alguien saque el caché pensando que sobraba.
Fijate cuántas vueltas lleva cada camino. La cantidad de vueltas importa tanto como quién tenía razón.
Lo que decide cuánto tarda un hilo
Cierre
Autoevaluación
¿Lo entendiste?
Práctica