Guía de inglés para code reviews

Comentarios en code reviews en inglés: órdenes, sugerencias y qué bloquea un merge

Cómo escribir comentarios en pull requests que sean claros, profesionales y no suenen accidentalmente bruscos o confusos.

Dejar un comentario en un code review parece sencillo. Ves un problema, escribes una nota, el otro developer lo arregla. Pero el lenguaje que usas lo cambia todo.

Hay una gran diferencia entre "Change this to black" y "Could you change this to black?" Uno suena como una orden de un senior a un junior. El otro es una sugerencia profesional entre compañeros. En inglés, esa distinción importa mucho, y es fácil equivocarse si aprendiste inglés sin enfocarte en contextos profesionales.

Órdenes vs alternativas: la diferencia que lo cambia todo

El inglés tiene muchas formas de hacer una petición sin que suene a una exigencia. Cuando escribes comentarios en code reviews, casi siempre querrás evitar el imperativo.

Hay dos técnicas principales. La primera es convertir el feedback en una pregunta: "Could you rename this?" La segunda es explicar el motivo sin dar una orden: "This should be removed before merging because it will show up in production logs." Las dos funcionan. Las preguntas invitan a colaborar; las afirmaciones con motivo explican el por qué sin exigir.

Aquí puedes ver cómo suena el mismo feedback como orden y como alternativa más profesional:

Orden

"Change the variable name to snake_case."

Alternativa

"Could you rename this to snake_case? It would be more consistent with the rest of the file."

Forma de pregunta: añade un motivo e invita al autor a actuar.

Orden

"Remove this console.log."

Alternativa

"This console.log should be removed before merging. It will show up in production logs."

Afirmación con motivo: no necesita signo de interrogación. Explicar el por qué lo hace profesional, no autoritario.

Orden

"Use a const here."

Alternativa

"I would use a const here since this value never changes. What do you think?"

Invitar a la opinión del autor hace que el review se sienta más colaborativo.

Orden

"This function is too long."

Alternativa

"This function is doing quite a bit. Do you think it could be split into two?"

Formular el feedback como pregunta suaviza el tono sin ocultar el punto.

Must-have vs nice-to-have: comunica la gravedad

No todos los comentarios de un review tienen el mismo peso. Algunos son bloqueantes: el PR no puede mergearse hasta que el problema esté resuelto. Otros son mejoras opcionales que dejas a criterio del autor. En equipos de habla inglesa, es habitual señalar esto de forma explícita.

Estas son las expresiones más comunes para comunicar la gravedad:

Blocking (bloqueante)

Úsalas cuando el código no puede llegar a producción tal como está.

"Blocking: this will throw a null pointer exception if the list is empty."
"This needs to be fixed before this can merge."
"Must fix: this introduces a security vulnerability."

Nit (nitpick)

Un nit es una preferencia de estilo pequeña y opcional. Nunca bloquea un merge.

"Nit: extra space here."
"Nit: I would rename this to make it clearer, but feel free to ignore."
"Minor nit: this could be a one-liner."

Optional / Nice-to-have

Son mejoras que sugieres pero no exiges.

"Optional: if you have time, this could be extracted into a helper."
"Nice-to-have: adding a test for this edge case would be great."
"Just a thought: would it be cleaner to use a map here instead?"

Question / Curiosity (pregunta)

Úsalas cuando no estás seguro de si algo es intencional. No son bloqueantes ni siquiera sugerencias, solo preguntas.

"Curious: why did you decide to use a list here instead of a set?"
"Question: is this intentional or a leftover from the last refactor?"
"Just checking: is this value ever null?"

Cuándo pedir un PR separado

Una de las partes más difíciles de revisar código es mantenerse enfocado en lo que el PR realmente debe hacer. Cuando encuentras algo no relacionado que hay que arreglar, es tentador pedirlo en el mismo PR. Pero eso genera scope creep y retrasa el merge.

La forma profesional de manejarlo es señalarlo sin bloquear:

Estas expresiones funcionan bien en esta situación:

"This is out of scope for this PR, but it is worth a follow-up ticket."
"Could this be done in a separate PR? I do not want to block this one."
"I noticed this while reviewing, but it deserves its own PR. I will open a ticket."
"This is related but separate enough that I would prefer to track it independently."
"Not blocking: this could be cleaned up in a follow-up."

Una historia real: 30 comentarios y un compañero que se lo tomó como algo personal

Hace unos años, revisé el pull request de un compañero más senior que yo. Leí el código con cuidado y dejé unos 30 comentarios.

No le sentó bien. Leyó 30 comentarios como un veredicto sobre sus habilidades, no como una lista de cosas que discutir. Se puso a la defensiva. Generó tensión en el equipo.

Mirando atrás, los comentarios eran correctos. Pero había cosas que podría haber hecho de otra manera:

Podría haber añadido un comentario general al principio: "Revisé esto con cuidado, en general se ve sólido. Dejé comentarios detallados abajo, principalmente sobre naming y casos extremos. Estoy disponible para hablar de cualquiera de ellos."

Eso cambia el tono de todo lo que viene después. En lugar de 30 problemas, el autor ve 30 notas de alguien que se tomó el tiempo de leer con atención.

Pero lo que quiero que te lleves es esto: recibir muchos comentarios en un PR no te convierte en un mal developer. Normalmente significa que tu reviewer lo leyó con cuidado. Los mejores PRs que he visto, de los engineers más senior, a menudo son los que más comentarios reciben. Porque los reviewers confían en que el autor quiere aprender y mejorar.

Si recibes 30 comentarios, responde a cada uno de forma profesional. Discute los que no te convencen. Arregla los que tienen sentido. Agradece al reviewer al final. Esa respuesta le dice mucho más a tu equipo sobre tus habilidades que el código original.

Frases útiles para responder a comentarios en reviews

Cuando estás de acuerdo y vas a corregirlo

"Good catch, I will fix this."
"You are right, updated."
"Makes sense, fixing now."

Cuando no estás de acuerdo y quieres discutirlo

"I see your point, but I went with this approach because..."
"Could you explain why you prefer X? I want to make sure I understand the reasoning."
"I think both approaches work here. What would you prefer?"

Cuando necesitas más contexto antes de decidir

"Good point. Let me check if this is covered elsewhere before changing it."
"I am not sure about this one. Can we discuss in the standup?"
"I will leave this for now and open a follow-up ticket."

Cuando el review está listo y quieres resumir

"I addressed all comments. Let me know if anything else needs attention."
"Updated based on the feedback. Ready for another round when you have time."
"Thanks for the thorough review, I learned a few things."

Referencia rápida: frases por tipo

Tipo	Frase de ejemplo
Must fix	This needs to be fixed before merging.
Blocking	Blocking: this will cause X.
Sugerencia	Could you consider...?
Opcional	Optional: if you have time, ...
Nit	Nit: minor style preference.
Pregunta	Curious: why did you...?
PR separado	This could be a follow-up ticket.
De acuerdo	Good catch, fixing now.
En desacuerdo	I see your point, but... because...

Sigue aprendiendo

¿Listo para practicar tu inglés en el trabajo?

Lingua-e tiene ejercicios interactivos basados en conversaciones reales de developers: standups, code reviews, retrospectivas y más. Practica hasta que salga solo.

Prueba Lingua-e gratis

Escrito por

Roxana Lafuente

Fundadora de Lingua-e

Roxana Lafuente es ingeniera de software con más de 8 años de experiencia. Al comienzo de su carrera, aunque ya había aprobado el First Certificate in English, se bloqueaba cada vez que tenía que hablar en el standup diario. Era un problema que nadie estaba resolviendo. Después de más de 2.000 standups, descubrió qué es lo que realmente construye la fluidez: practicar situaciones que se parecen a tu trabajo real. Creó Lingua-e para que otros developers no tuvieran que tomar el camino largo para sentirse seguros trabajando en un entorno de desarrollo internacional.