Guía definitiva de abreviaturas en Code Reviews

Revisas un PR y lees:

LGTM NIT RFC R-

Si no entiendes estas siglas, pierdes contexto y agilidad. En una code review, comunicar claramente y rápido importa para mejorar la calidad y colaborar mejor.

Aquí tienes las abreviaturas más usadas en equipos técnicos, con significado en inglés y cuándo las usas.

Guárdatelo. Lo vas a ver cada semana.

✅ Aprobación

LGTM — Looks Good To Me

👉 “Me parece bien”
La usas cuando apruebas el PR sin cambios relevantes.

Ejemplo:

LGTM. Nice refactor.

R+ — Approved

👉 “Aprobado”
Similar a LGTM. Se usa en algunos repos como señal formal de aprobación.

ACK — Acknowledged

👉 “Recibido / entendido”

Confirma que has visto el comentario y que lo tienes en cuenta.

❌ Bloqueo

R- — Changes Requested

👉 “Cambios requeridos”
Indica que el PR no puede mergearse todavía.

BLOCKER — Blocking Issue

👉 “Bloqueante”
Algo que hay que resolver sí o sí antes de mergear.

Ejemplo:

BLOCKER: This can cause an ANR on the main thread.

NACK — Negative Acknowledgement

👉 “No aprobado”
Muestras desacuerdo claro con la propuesta.

💬 Sugerencias y contexto

NIT — Nitpick

👉 “Detalle menor”
Cambio no bloqueante: naming, formato, claridad.

Ejemplo:

NIT: I’d rename this to userRepository.

No frenes un PR por esto.

PTAL — Please Take A Look

👉 “Échale un vistazo”
Pides review explícitamente.

RFC — Request For Comments

👉 “Solicitud de comentarios”
Buscas feedback antes de cerrar la solución.

Ideal para decisiones de arquitectura.

WIP — Work In Progress

👉 “Trabajo en progreso”
El PR no está listo para mergear.

POC — Proof Of Concept

👉 “Prueba de concepto”
Código exploratorio. No es versión final.

CDC — Clean, Documented, Covered

👉 “Limpio, documentado y cubierto por tests”
Recuerda que el PR debe cumplir mínimos de calidad.

🧠 Diseño y principios

Estas no son solo siglas.
Son recordatorios de buenas prácticas.

SRP — Single Responsibility Principle

👉 Responsabilidad única
Una clase hace demasiadas cosas.

DRY — Don’t Repeat Yourself

👉 No te repitas
Detectas código duplicado.

KISS — Keep It Simple, Stupid

👉 Hazlo simple
Evitas sobreingeniería.

YAGNI — You Aren’t Gonna Need It

👉 No lo vas a necesitar
Frenas features innecesarias.

🧪 Tests

UT — Unit Test

👉 Test unitario
Valida lógica aislada.

IT — Integration Test

👉 Test de integración
Comprueba interacción entre módulos.

E2E — End To End

👉 Test de extremo a extremo
Valida el flujo completo.

TDD — Test Driven Development

👉 Desarrollo guiado por tests.

Define tests antes de la implementación.

⚙️ Android específico

ANR — Application Not Responding

👉 La app no responde
Bloqueas el main thread.

OOM — Out Of Memory

👉 Sin memoria
Tienes leaks o cargas excesivas.

🏁 Cómo usar estas siglas bien

Aquí está la clave.

No abuses de NIT.
Marca claramente lo que es BLOCKER.
Sé específico cuando pongas R-.
Usa RFC cuando tengas dudas reales.
Prioriza claridad sobre ego.

Una buena code review no busca tener razón, busca mejorar el código y hacer crecer al equipo.

Si revisas código cada semana, dominar este lenguaje te hace comunicarte mejor y crecer como Developer.

Guárdalo. Compártelo con tu equipo y sigue revisando código con criterio.