|
| 1 | +# Control de deuda técnica con herramientas CI/CD modernas |
| 2 | +## Jesus Antonio Triana Corvera C20212681 |
| 3 | +### Definición general |
| 4 | +La **deuda técnica** es el costo adicional que surge cuando se elige una **solución rápida** (atajo de diseño, código mal estructurado, falta de pruebas) en lugar de una solución más adecuada pero más costosa en tiempo. |
| 5 | +El término fue introducido por **Ward Cunningham** en 1992 y sigue siendo fundamental en ingeniería de software moderna. |
| 6 | + |
| 7 | +### Características principales |
| 8 | +- Es **inevitable**: todo sistema acumula deuda técnica, incluso si se siguen buenas prácticas. |
| 9 | +- Es **medible**: herramientas modernas permiten cuantificarla (ej. líneas duplicadas, complejidad ciclomática). |
| 10 | +- Es **gestionable**: puede priorizarse como parte del backlog. |
| 11 | +- Es **contagiosa**: si no se controla, se expande a otros módulos del sistema. |
| 12 | + |
| 13 | +### Tipologías de deuda técnica |
| 14 | +1. **Intencional y estratégica**: asumida con plena consciencia, como acelerar un prototipo. |
| 15 | +2. **No intencional**: aparece por falta de experiencia o desconocimiento técnico. |
| 16 | +3. **Por evolución tecnológica**: software que queda obsoleto frente a librerías y frameworks modernos. |
| 17 | +4. **De proceso**: prácticas de desarrollo mal definidas, falta de pruebas, integración manual. |
| 18 | + |
| 19 | +### Impacto en el ciclo de vida del software |
| 20 | +- **Desarrollo inicial**: deuda baja, pero se generan compromisos por decisiones rápidas. |
| 21 | +- **Mantenimiento**: la deuda empieza a ralentizar la entrega de nuevas funciones. |
| 22 | +- **Escalabilidad**: arquitecturas frágiles colapsan bajo nuevas exigencias. |
| 23 | +- **Producción**: errores recurrentes, incidentes y altos costos de corrección. |
| 24 | + |
| 25 | +**Ejemplo real**: El bug del *Ariane 5* (1996) costó $370M por reutilizar código de Ariane 4 sin refactorizar ni probar, acumulando una deuda técnica no gestionada. |
| 26 | + |
| 27 | +--- |
| 28 | + |
| 29 | +### Herramientas CI/CD que ayudan a gestionar deuda técnica |
| 30 | + |
| 31 | +- **SonarQube** |
| 32 | + - Detecta *code smells*, duplicación de código, cobertura de pruebas y métricas de mantenibilidad. |
| 33 | + - Define **Quality Gates**: si no se cumplen umbrales (ej. menos de 5% de duplicación, 80% de cobertura), el pipeline falla. |
| 34 | + - Métrica clave: *Technical Debt Ratio* (proporción entre deuda y esfuerzo de desarrollo). |
| 35 | + |
| 36 | +- **Snyk / OWASP Dependency-Check** |
| 37 | + - Identifican vulnerabilidades conocidas en dependencias de proyectos. |
| 38 | + - Notifican CVEs críticas que deben ser parchadas antes de desplegar. |
| 39 | + - Ejemplo: una librería vulnerable como *Log4j* puede ser bloqueada automáticamente. |
| 40 | + |
| 41 | +- **Dependabot / Renovate** |
| 42 | + - Automatizan la actualización de dependencias y frameworks. |
| 43 | + - Previenen la acumulación de deuda por versiones obsoletas. |
| 44 | + |
| 45 | +- **Jenkins / GitHub Actions / GitLab CI** |
| 46 | + - Permiten pipelines que integran pruebas, análisis estático, análisis dinámico y despliegues condicionales. |
| 47 | + - Implementan estrategias de **“shift-left testing”**: detectar problemas lo más temprano posible. |
| 48 | + |
| 49 | +--- |
| 50 | + |
| 51 | +### Comparación: Pipeline con vs. sin control de deuda |
| 52 | + |
| 53 | +| Aspecto | Sin control de deuda técnica | Con control de deuda técnica (Quality Gates) | |
| 54 | +|---------------------------|--------------------------------------------|----------------------------------------------| |
| 55 | +| **Velocidad inicial** | Alta, se despliega rápido. | Moderada, validaciones adicionales. | |
| 56 | +| **Mantenimiento** | Costoso, cada cambio rompe funcionalidades.| Más estable, los refactors se aplican antes. | |
| 57 | +| **Seguridad** | Vulnerabilidades pasan desapercibidas. | Alertas automáticas y parches inmediatos. | |
| 58 | +| **Moral del equipo** | Baja, trabajar en “código sucio” frustra. | Alta, código más legible y predecible. | |
| 59 | +| **Escalabilidad** | Riesgo de colapso. | Preparado para crecimiento futuro. | |
| 60 | + |
| 61 | +**Conclusión**: invertir tiempo en control de deuda técnica ralentiza entregas iniciales, pero ahorra enormes costos en el mediano y largo plazo. |
| 62 | + |
| 63 | +--- |
| 64 | + |
| 65 | +### Refactorización como estrategia de pago de deuda |
| 66 | +Refactorizar significa **mejorar el código sin alterar su comportamiento externo**. |
| 67 | +Ejemplos comunes: |
| 68 | +- Dividir métodos grandes en métodos más pequeños. |
| 69 | +- Eliminar duplicación usando herencia, interfaces o patrones. |
| 70 | +- Renombrar variables y clases para mayor legibilidad. |
| 71 | +- Añadir pruebas unitarias a código crítico. |
| 72 | + |
| 73 | +**Cómo CI/CD apoya el refactor**: |
| 74 | +- SonarQube detecta complejidad y duplicación → obliga al refactor. |
| 75 | +- Jenkins/GitHub Actions ejecutan pruebas tras refactor para garantizar que nada se rompe. |
| 76 | + |
| 77 | +### Patrones de diseño como prevención de deuda |
| 78 | +- **Strategy**: sustituye condicionales por polimorfismo → evita duplicación. |
| 79 | +- **Factory Method / Abstract Factory**: centralizan la creación de objetos → evitan código rígido. |
| 80 | +- **Observer**: desacopla componentes → facilita escalabilidad. |
| 81 | +- **Decorator**: agrega responsabilidades sin modificar código existente. |
| 82 | +- **Singleton (bien aplicado)**: previene instanciación excesiva, aunque mal uso puede generar deuda. |
| 83 | + |
| 84 | +### Relación con calidad y principios de diseño |
| 85 | +- **SOLID**: aplicar principios de responsabilidad única, inversión de dependencias, etc., evita deuda. |
| 86 | +- **Clean Code (Robert C. Martin)**: fomenta nombres claros, funciones cortas y simplicidad. |
| 87 | +- **Refactor continuo**: apoyado en pipelines CI/CD, convierte la deuda en algo monitoreado constantemente. |
| 88 | + |
| 89 | +--- |
| 90 | + |
| 91 | +### En entornos profesionales |
| 92 | +- Casos reales: |
| 93 | + - **Equifax (2017)**: no actualizó *Apache Struts*, deuda técnica derivó en la filtración de datos de 147M personas. |
| 94 | + - **Knight Capital (2012)**: software obsoleto causó pérdidas de 440M USD en 45 minutos. |
| 95 | + |
| 96 | +### Reflexión crítica |
| 97 | +La deuda técnica **no debe eliminarse completamente**, ya que en ocasiones estratégicas es válida para sacar más rápido el producto sin embargo, no debemos abusar de ella. Considero que los patrones de diseño nos pueden ayudar a evitar este tipo de deudas, al ofrecer un "manual" de soluciones aplicadas al software que ya han demostrado funcionar, brindando así alternativas claras para la resolución de problemas. El verdadero problema surge cuando la deuda técnica **no se documenta, mide ni controla**, pues en ese punto se convierte en una carga invisible que frena el desarrollo. En este sentido, las herramientas CI/CD cumplen un rol esencial al actuar como **auditores automáticos** que hacen visible lo invisible y permiten gestionar la deuda de manera disciplinada y sostenible. |
| 98 | + |
| 99 | +--- |
| 100 | + |
0 commit comments