¿Qué es un PR, en esencia?

Un Pull Request no es un artefacto técnico.

Es una práctica social que revela cómo un equipo piensa, aprende y toma decisiones.

Bien entendidos, los PRs encarnan principios clave de mejora continua, agilidad y creación de valor.

Un Pull Request no es solo un mecanismo para fusionar código.

En su mejor versión, un PR es:

Una conversación estructurada para validar decisiones técnicas antes de que se vuelvan irreversibles.

Código incluido, pero no limitado al código.

¿Qué problemas intenta resolver un PR?

Bien usado, un PR busca:

1. Reducir riesgo técnico
2. Compartir contexto y conocimiento
3. Detectar errores temprano (shift left vive aquí)
4. Alinear criterios de calidad
5. Evitar decisiones solitarias con impacto colectivo

Mal usado… hace exactamente lo contrario 😅

Qué NO es

(aunque muchas veces se trate como tal)

❌ No es:

• Un trámite burocrático
• Un “permiso para mergear”
• Un lugar para correcciones cosméticas tardías
• Un sustituto de diseño o arquitectura
• Un examen de ego (“a ver si pillo algo”)

Señales de PRs enfermos

• PRs gigantes “porque había que avanzar”
• Reviews tardías o automáticas (“LGTM 👍”)
• Comentarios solo de estilo
• Conflictos que aparecen después del merge
• El mismo reviewer siempre ⚠️
• Miedo a comentar (“no quiero molestar”)

Qué SÍ debería ser un PR sano

1. Una unidad de cambio entendible

Un PR debería responder claramente:

• ¿Qué problema resuelve?
• ¿Por qué esta solución?
• ¿Qué alternativas se descartaron?
• ¿Qué riesgos introduce?

👉 Si no se puede explicar en pocas líneas, el PR probablemente es demasiado grande.

2. Un mecanismo de aprendizaje colectivo

Un buen PR:

• Explica decisiones
• Deja trazabilidad
• Enseña al equipo

👉 El valor no está solo en aprobarlo, sino en leerlo y entenderlo.

3. Un punto de control temprano (Shift Left real)

El PR es el último lugar barato para corregir cosas como:

• Diseño pobre
• Naming confuso
• Casos borde ignorados
• Deuda técnica innecesaria
• Riesgos no conversados

👉 Después del merge, el costo sube.

4. Un acuerdo explícito de calidad

El PR hace visible:

• Qué entendemos por “listo”
• Qué se tolera
• Qué no se negocia

👉 Cada PR refuerza (o degrada) el estándar del equipo.

LGTM

LGTM es un acrónimo muy común en desarrollo de software que significa:

LGTM = Looks Good To Me (“Se ve bien para mí”)

Se usa típicamente como comentario en un Pull Request (PR) para indicar aprobación.

¿Qué implica decir LGTM?

En teoría, cuando alguien escribe LGTM, está diciendo:

• He revisado el código
• Entiendo el cambio
• No veo problemas relevantes
• Estoy de acuerdo con que se haga el merge

👉 Es una señal de aprobación.

Regla práctica útil

<aside> ☝

</aside>

LGTM bien usado (sí, se puede)

LGTM funciona cuando cierra una conversación, no cuando la reemplaza.

Ejemplo sano:

“Revisé el manejo de errores y los casos borde. LGTM.”

O:

“Probé el flujo localmente, los tests pasan. LGTM.”

👉 Aquí LGTM resume una revisión, no la simula.

👉 El conocimiento deja de estar en la cabeza de uno y pasa al equipo.

Un PR sano no pregunta:

“¿Está bien el código?”