💡 Key Takeaways
- The First 30 Seconds: What the PR Description Tells You
- Size Matters: The 400-Line Rule
- The Business Logic Layer: Where Most Bugs Live
- Error Handling: The Difference Between Good and Great Code
Hace tres años, aprobé una solicitud de extracción que le costó a mi empresa $47,000 en ingresos perdidos durante un solo fin de semana. El código se veía bien. Las pruebas pasaron. La lógica parecía sólida. Pero me perdí algo sutil en cómo manejamos las conversiones de zona horaria para nuestro sistema de facturación por suscripción, y los clientes en ciertas regiones fueron cobrados dos veces.
💡 Puntos Clave
- Los Primeros 30 Segundos: Lo Que Te Dice la Descripción de la PR
- El Tamaño Importa: La Regla de las 400 Líneas
- La Capa de Lógica de Negocios: Donde Viven la Mayoría de los Errores
- Manejo de Errores: La Diferencia Entre Buen y Gran Código
Ese incidente cambió cómo reviso código para siempre. Soy Sarah Chen, y he sido gerente de ingeniería senior en tres diferentes empresas SaaS durante la última década, revisando un promedio de 15-20 solicitudes de extracción por semana. Eso es aproximadamente 8,000 PRs en mi carrera. He visto código brillante que envió errores, y código desordenado que funcionó a la perfección en producción durante años. He aprendido que la revisión de código no se trata de encontrar errores de sintaxis: tu linter hace eso. Se trata de detectar los problemas invisibles que solo la experiencia puede revelar.
Este artículo es la lista de verificación que desearía haber tenido cuando empecé. No es exhaustiva; ninguna lista de verificación podría serlo, pero representa los patrones que he aprendido a reconocer, las preguntas que me he entrenado a hacer y los modelos mentales que han salvado a mis equipos de innumerables incidentes de producción.
Los Primeros 30 Segundos: Lo Que Te Dice la Descripción de la PR
Antes de mirar una sola línea de código, paso 30 segundos leyendo la descripción de la PR. Esto puede parecer al revés, pero he encontrado que el 60% de las PRs problemáticas se revelan inmediatamente a través de una mala comunicación. Una buena descripción de PR responde tres preguntas: qué cambió, por qué cambió y qué podría salir mal.
Cuando veo una descripción que dice "se corrigió un error" o "se actualizó un componente", sé inmediatamente que esta revisión tomará más tiempo. El autor no ha pensado en las implicaciones de sus cambios, lo que significa que necesito hacer ese trabajo por ellos. Por el contrario, cuando veo una descripción que dice "Reestructurada la autenticación de usuario para usar tokens JWT en lugar de cookies de sesión. Esto reduce la carga en la base de datos en un 40% durante las horas pico, pero requiere que los clientes manejen la actualización del token. Riesgo: las versiones existentes de la aplicación móvil (< 2.3) tendrán que reautenticarse", sé que el autor ha hecho su tarea.
Busco métricas específicas en la descripción. No mejoras vagas, sino números reales. "Mejoró el rendimiento" no significa nada. "Redujo el tiempo de respuesta de la API de 340 ms a 180 ms para el endpoint del perfil de usuario bajo 1000 solicitudes concurrentes" me dice que el autor midió su trabajo y entiende el impacto. En mi experiencia, los desarrolladores que incluyen métricas en sus descripciones de PR escriben código más reflexivo en general.
La descripción también debería enlazar a un contexto relevante: el ticket, el documento de diseño, la conversación de Slack donde se discutió el enfoque. Si estoy revisando una PR en aislamiento, sin entender el contexto más amplio, me voy a perder cosas. Una vez aprobé una "simple reestructuración" que sin saberlo rompió una integración crítica porque no conocía una dependencia que no estaba documentada en ningún lado excepto en un hilo de correo electrónico de hace tres meses.
Las señales de advertencia en las descripciones de PR incluyen: ninguna descripción en absoluto, descripciones que son más largas que los cambios de código en sí (normalmente indica sobreingeniería), descripciones que dicen "WIP" o "borrador", pero la PR está marcada como lista para revisión, y descripciones que incluyen frases como "no estoy seguro de si este es el enfoque correcto" (entonces, ¿por qué me pides que la revise?).
El Tamaño Importa: La Regla de las 400 Líneas
Tengo una regla estricta: no reviso a fondo PRs más grandes de 400 líneas de cambios de código reales (excluyendo código generado, archivos package-lock y fixtures de prueba). Esto no es arbitrario. La investigación de Cisco y SmartBear muestra que la efectividad de la revisión de código disminuye drásticamente después de 400 líneas, y mi propia experiencia lo confirma. Después de revisar alrededor de 200 líneas de código, mi cerebro comienza a perder detalles. A las 400 líneas, básicamente solo estoy hojeando.
"La revisión de código no se trata de encontrar errores de sintaxis: tu linter hace eso. Se trata de detectar los problemas invisibles que solo la experiencia puede revelar."
Cuando alguien envía una PR de 1,200 líneas, les pido que la dividan. No me importa si "todo está relacionado". Las grandes PRs son donde se esconden los errores. He visto vulnerabilidades críticas de seguridad pasar desapercibidas en enormes PRs de reestructuración porque los revisores se fatigaron y dejaron de prestar atención alrededor de la línea 600. La vulnerabilidad estaba en la línea 847.
Por supuesto, hay excepciones. A veces necesitas mover archivos, o actualizar código generado, o hacer cambios drásticos para cumplir con un nuevo estándar de linting. En esos casos, pido al autor que separe los cambios mecánicos de los cambios lógicos. Envía los movimientos de archivos en una PR, los cambios lógicos reales en otra. Esto hace que ambas PRs sean más fáciles de revisar y más fáciles de revertir si algo sale mal.
También presto atención a la proporción de código añadido en comparación con el código eliminado. En mi experiencia, las mejores PRs tienen un conteo neto de líneas negativo: logran algo mientras hacen que la base de código sea más pequeña. Cuando veo una PR que añade 500 líneas y elimina 50, me pongo suspicaz. ¿Estamos añadiendo complejidad? ¿Estamos duplicando funcionalidad existente? ¿Es el autor consciente de lo que ya está en la base de código?
El problema de tamaño se extiende también a archivos individuales. Si una PR toca 30 archivos diferentes, incluso si el conteo total de líneas es razonable, eso es una señal de advertencia. Sugiere que el cambio está mal delimitado o que la base de código tiene problemas de acoplamiento. De cualquier manera, merece un examen más minucioso.
La Capa de Lógica de Negocios: Donde Viven la Mayoría de los Errores
Después de una década de revisiones de código, puedo decirte dónde se esconden los errores: en la capa de lógica de negocios, específicamente en los casos límite y las transiciones de estado. No en los componentes de la interfaz de usuario. No en las consultas a la base de datos. En el código que implementa tus verdaderas reglas de negocio.
| Calidad de la Descripción de la PR | Lo Que Dice | Tiempo de Revisión | Nivel de Riesgo |
|---|---|---|---|
| Pobre | "se corrigió un error" o "se actualizó un componente" | 2-3x más largo | Alto |
| Adecuada | Lo básico de qué y por qué, sin análisis de riesgo | Normal | Medio |
| Buena | Claro qué, por qué y potenciales riesgos identificados | Eficiente | Bajo |
| Excelente | Contexto integral, compensaciones discutidas, casos límite anotados | Rápido | Muy Bajo |
Cuando reviso lógica de negocios, busco supuestos. Cada supuesto es un potencial error. Una vez revisé código para un sistema de cálculo de descuentos que asumía que todos los descuentos eran porcentajes. El código funcionó perfectamente hasta que el marketing quería ofrecer una promoción de "$10 de descuento". El sistema colapsó porque alguien dividió por el monto del descuento, y dividir por 10 cuando esperabas un número entre 0 y 1 produce resultados muy incorrectos.
Me pregunto: ¿qué pasa en los límites? ¿Qué sucede si la entrada es cero? ¿Qué pasa si es negativa? ¿Qué pasa si es nula? ¿Qué sucede si es una cadena vacía frente a una cadena nula? ¿Qué pasa si el array está vacío? ¿Qué pasa si el usuario no tiene permisos? ¿Qué pasa si tiene todos los permisos? ¿Qué pasa si la base de datos no devuelve resultados? ¿Qué pasa si devuelve un millón de resultados?
Busco números mágicos en la lógica de negocios. Cuando veo if (user.loginAttempts > 5), pregunto: ¿por qué 5? ¿Está documentado? ¿Es configurable? ¿Qué pasa si queremos cambiarlo a 3 para ciertos tipos de usuario? Los números mágicos en la lógica de negocios son una deuda técnica esperando a suceder.
Las máquinas de estado son otra fuente común de errores. Cuando veo código que maneja transiciones de estado—estado del pedido, ciclo de vida del usuario, etapas de flujo de trabajo—dibujo el diagrama de estado en mi cabeza. ¿Están contabilizadas todas las transiciones? ¿Puedes entrar en un estado inválido? Una vez atrapé un error donde un usuario podía ser simultáneamente "activo" y "suspendido" porque el código que configuraba un estado no comprobaba el otro.
🛠 Explora Nuestros Herramientas
También presto atención a la lógica de negocios que está repartida a través de múltiples capas. Si veo validación en la interfaz de usuario, más validación en la API, y aún más validación en la capa de base de datos, sé que vamos a tener inconsistencias. Las reglas de negocio deberían residir en un solo lugar, y ese lugar debería ser obvio.