Saltar al contenido principal

​
Qué es la Tasa de Error en Cambios

La Tasa de Error en Cambios mide el porcentaje de Pull Requests que son correcciones de errores o correcciones en relación con el número total de PRs. Esta métrica te ayuda a entender cuánto esfuerzo de desarrollo se dedica a corregir problemas versus crear nuevas funciones. También puede leerse como “Change Failure Rate”: la tasa a la que los cambios resultan en fallos.

​
Cómo la Calculamos

Identificamos automáticamente qué PRs son correcciones de errores usando modelos de lenguaje de IA (LLM) que analizan los nombres y descripciones de los Pull Requests. Luego el sistema calcula el porcentaje de trabajo relacionado con errores en relación con tu actividad total de PRs. Lo que Rastreamos:
  • PRs identificados como correcciones de errores por análisis de IA
  • Número total de PRs en el período
  • El porcentaje de trabajo relacionado con errores
Cómo se Calcula: 
Tasa de Error = (PRs de Corrección de Errores) ÷ (Total de PRs) × 100
Por ejemplo, si 3 de 15 PRs se identifican como correcciones de errores, tu tasa de error es del 20%. Cómo Identificamos las Correcciones de Errores: Usamos modelos de lenguaje avanzados para analizar los títulos de los PRs y clasificarlos automáticamente. La IA busca patrones como:
  • “Fix bug in…” o “Bug fix for…”
  • “Resolve issue with…” o “Fix problem in…”
  • “Patch for…” o “Hotfix:…”

​
Por qué es Importante

La Tasa de Error en Cambios es un indicador clave del enfoque de desarrollo de tu equipo y la calidad del código. Comprender esta tasa te ayuda a:
  • Enfoque de Desarrollo: Ver cuánto tiempo se dedica a corregir versus construir
  • Calidad del Código: Identificar si se está invirtiendo demasiado tiempo en errores
  • Mejora del Proceso: Entender si tu proceso de desarrollo necesita optimización
  • Planificación de Recursos: Planificar cuánto esfuerzo asignar a las correcciones de errores

​
Cómo Mejorar

  • Implementar estrategias de prueba integrales (unitarias, de integración, E2E)
  • Usar herramientas automatizadas (linters, analizadores estáticos) antes de producción
  • Asegurar revisiones de código exhaustivas para todos los cambios
  • Dividir las funciones grandes en partes más pequeñas y comprobables
  • Usar feature flags para implementaciones más seguras
  • Realizar revisiones post-incidente para prevenir la recurrencia

​
Mejores Prácticas para Nombrar PRs

Para ayudar a la IA a identificar con precisión las correcciones de errores, considera estas convenciones de nomenclatura:

​
Buenos Nombres para PRs de Corrección de Errores

  • “Fix: User login fails with invalid credentials”
  • “Bug fix: Memory leak in data processing module”
  • “Resolve issue: API returns 500 error for large requests”
  • “Patch: Fix null pointer exception in user service”

​
Evita Nombres Vagos

  • “Fix stuff” o “Bug fix”
  • “Update code” o “Improve performance”
  • “Fix things” o “Resolve issues”

​
Corrección de Error vs. Nueva Función

  • Corrección de Error: “Fix: Payment validation fails for expired cards”
  • Nueva Función: “Add: New payment method support”
  • Mejora: “Enhance: Payment validation error messages”