5 min lectura • Guide 76 of 877
Métricas y Seguimiento de Calidad de Código
La calidad de código impacta directamente la velocidad de desarrollo, tasas de bugs y moral del equipo. Rastrear métricas de calidad ayuda a los equipos a identificar áreas problemáticas antes de que se vuelvan críticas. GitScrum se integra con herramientas de desarrollo para hacer visible la calidad junto con el progreso del proyecto.
Dimensiones de Calidad de Código
| Dimensión | Métricas | Impacto |
|---|---|---|
| Confiabilidad | Densidad bugs, MTTR | Experiencia usuario |
| Mantenibilidad | Complejidad, duplicación | Velocidad desarrollo |
| Seguridad | Vulnerabilidades, OWASP | Exposición a riesgos |
| Performance | Tiempo carga, eficiencia | Satisfacción usuario |
| Testabilidad | Cobertura, calidad tests | Confianza para cambiar |
Framework de Métricas Clave
Métricas Core
MÉTRICAS DE CALIDAD DE CÓDIGO
═════════════════════════════
MÉTRICAS DE COBERTURA:
├── Cobertura de líneas: % líneas testeadas
├── Cobertura de branches: % branches testeados
├── Cobertura de funciones: % funciones testeadas
└── Objetivo: 70-80% (depende del contexto)
MÉTRICAS DE COMPLEJIDAD:
├── Complejidad ciclomática por función
├── Complejidad cognitiva
├── Líneas por archivo/función
└── Profundidad de anidamiento
MÉTRICAS DE DUPLICACIÓN:
├── % líneas duplicadas
├── Bloques duplicados
├── Detección de copy-paste
└── Objetivo: <5% duplicación
DEUDA TÉCNICA:
├── Ratio de deuda (deuda/tiempo dev)
├── Deuda en horas/días
├── Deuda por componente
└── Tendencia en el tiempo
Métricas de Review
MÉTRICAS DE CODE REVIEW
═══════════════════════
VELOCIDAD:
├── Tiempo hasta primera revisión
├── Tiempo hasta merge
├── Ciclos de revisión
└── Distribución de edad de PR
CALIDAD:
├── Comentarios por PR
├── Tasa de aprobación
├── Solicitudes de retrabajo
└── Profundidad de revisión
PARTICIPACIÓN:
├── Reviews por persona
├── Distribución de reviews
├── Carga de trabajo de revisores
└── Dispersión de conocimiento
OBJETIVOS:
├── Primera revisión: <4 horas
├── Tiempo a merge: <24 horas
├── Ciclos de revisión: <2
└── Todos los miembros revisando
Dashboard de Calidad en GitScrum
Vista Integrada
LAYOUT DE DASHBOARD DE CALIDAD
══════════════════════════════
┌─────────────────────────────────────────────────┐
│ Resumen de Calidad de Código │
│ Última actualización: hace 5 min │
├─────────────────────────────────────────────────┤
│ │
│ PUNTUACIÓN DE SALUD │
│ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░ 78/100 (↑ 3 pts) │
│ │
├────────────┬────────────┬────────────┬──────────┤
│ Cobertura │Complejidad │Duplicación │ Deuda │
│ 72% ↑ │ 12 ↓ │ 3.2% = │ 4.2d ↓ │
│ Obj:70% │ Obj:<15 │ Obj:<5% │ │
└────────────┴────────────┴────────────┴──────────┘
│ │
│ TENDENCIA (Últimos 30 Días) │
│ │
│ Cobertura: ────────────────────▲ │
│ Deuda: ────────▼────────────── │
│ Bugs: ────────────────────── │
│ │
└─────────────────────────────────────────────────┘
Calidad por Componente
TABLA DE CALIDAD POR COMPONENTE:
┌─────────────────────────────────────────────────────────────┐
│ COMPONENTE │ COBERT. │ COMPLEJIDAD │ DEUDA │ ESTADO │
├───────────────┼─────────┼─────────────┼───────┼────────────┤
│ Frontend │ 78% │ 8 │ 2d │ 🟢 Bueno │
│ API │ 85% │ 12 │ 1d │ 🟢 Bueno │
│ Auth Service │ 92% │ 6 │ 0.5d │ 🟢 Excelent│
│ Legacy Module │ 45% │ 22 │ 8d │ 🔴 Crítico │
│ Utils │ 68% │ 5 │ 1d │ 🟡 Regular │
└─────────────────────────────────────────────────────────────┘
ACCIONES SUGERIDAS:
• Legacy Module: Priorizar refactoring
• Utils: Agregar más tests
Integraciones
Herramientas de Calidad
INTEGRACIONES SOPORTADAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANÁLISIS DE CÓDIGO: │
│ ├── SonarQube / SonarCloud │
│ ├── CodeClimate │
│ ├── Codacy │
│ └── ESLint / Pylint reports │
│ │
│ COBERTURA: │
│ ├── Codecov │
│ ├── Coveralls │
│ └── Reportes de Jest/pytest │
│ │
│ SEGURIDAD: │
│ ├── Snyk │
│ ├── Dependabot │
│ └── OWASP Dependency Check │
│ │
│ CI/CD: │
│ ├── GitHub Actions │
│ ├── GitLab CI │
│ └── Jenkins │
│ │
└─────────────────────────────────────────────────────────────┘
Usando Métricas Efectivamente
Evitando Anti-Patrones
QUÉ EVITAR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ ANTI-PATRONES: │
│ │
│ • Enforcement rígido de porcentajes │
│ → Lleva a tests de baja calidad para cumplir número │
│ │
│ • Métricas como castigo │
│ → Equipo las evita en lugar de mejorar │
│ │
│ • Demasiadas métricas │
│ → Parálisis de análisis, foco disperso │
│ │
│ • Ignorar contexto │
│ → No todo código necesita 100% cobertura │
│ │
│ ✅ MEJORES PRÁCTICAS: │
│ │
│ • Enfocarse en tendencias, no absolutos │
│ • Usar métricas para conversación, no punición │
│ • Priorizar métricas que correlacionan con outcomes │
│ • Adaptar objetivos al contexto del proyecto │
│ │
└─────────────────────────────────────────────────────────────┘