La deuda técnica es un término acuñado para expresar “los problemas que se presentan en el momento donde uno de los aspectos planificados para el proyecto es priorizado sobre otro, comúnmente se presenta al priorizar los tiempos de entrega sobre los estándares de calidad.” Matalonga, S., Villar, A., & Nacimento, C. (2013).
Aunque este término tiene su concepto concreto, su aplicación en los proyectos de software y empresas aún se encuentra en desarrollo. “Es una problemática que aqueja a los equipos de desarrollo en toda la vida del software y debe ser saldada en algún momento.” Matalonga, S., Villar, A., & Nacimento, C. (2013).
Pero la deuda técnica no es solamente un problema, si esta es incluida de manera controlada, puede llevar los proyectos de software a una entrega según los tiempos planificados y con futuras actualizaciones que se deben encargar de pagar las deudas que se inyectaron al proyecto para preservar la calidad del sistema y su escalabilidad futura.
Miremos un ejemplo más específico de deuda técnica, para un proyecto de software se define una arquitectura basada en capas donde cada una de las capas se comunica con la inferior para hacer peticiones y con la superior para dar respuesta a estas.
El proyecto se encuentra retrasado a solamente una semana de su entrega y aun se deben terminar un par de funcionalidades, por este motivo el equipo de desarrollo acuerda aplicar una deuda técnica en la cual se violará la arquitectura basada en capas para que las peticiones sean directas entre la capa de presentación y la capa de persistencia saltándose la capa de negocio lo cual agilizara el proceso para codificar las funcionalidades restantes.
El equipo logra terminar a tiempo y el proyecto es entregado, ¿qué ocurre si esta deuda no es pagada?, la estabilidad del proyecto se ve afectada y entre más se retrase su pago, más complicado será pagarla.
Pero si el equipo decide ir pagando esta deuda a medida que realizan las diversas actualizaciones al software, esta deuda no supondrá un problema más adelante y habrá sido aplicada de la manera correcta en la cual se utilizó como una forma de cumplir tiempos, pero teniendo presente las violaciones a la arquitectura para ser ajustadas en tiempo.
A continuación, conozcamos unos cuantos casos de deuda técnica en el código que son mejor conocidos como Code Smells:
Bloaters
Bloaters son código, métodos y clases que han aumentado a proporciones tan gigantescas que es difícil trabajar con ellos. Por lo general, estos smells no surgen de inmediato, sino que se acumulan con el tiempo a medida que el programa evoluciona (y especialmente cuando nadie hace un esfuerzo por erradicarlos).
Object-Orientation Abusers
Todos estos smells son aplicaciones incompletas o incorrectas de los principios de programación orientada a objetos.
Change Preventers
Estos smells significan que, si es necesario cambiar algo en un lugar de su código, también debe realizar muchos cambios en otros lugares. Como resultado, el desarrollo del programa aumenta en su dificultad y su costo.
Dispensables
Es algo sin sentido e innecesario cuya ausencia haría que el código fuera más limpio, más eficiente y más fácil de entender.
Couplers
Todos los smells de este grupo contribuyen al acoplamiento excesivo entre clases o muestran lo que sucede si el acoplamiento se reemplaza por una delegación excesiva.
Para detectar la deuda técnica a futuro nos podemos ayudar con herramientas de test de calidad del aplicativo, que nos arrojaran los posibles problemas que se presenten, como lo es, la duplicidad de cogido, redundancia de funciones, clases o métodos mal estructurados o nombrados, y/o eficiencia del aplicativo, entre otras.
- SonarQube: Es una herramienta encargada de la revisión automática de código para detectar errores, vulnerabilidades y Code smells en su código. Puede ser integrada con su flujo de trabajo existente para permitir la inspección continua del código en las ramas de su proyecto y solicitudes de extracción.
Esta herramienta ayuda a que podamos escribir código más limpio y la reducción de un término muy importante que es la deuda técnica.
- CodeScene: Es una herramienta de análisis de código de comportamiento desarrollada por Empear AB. CodeScene proporciona visualizaciones de código basadas en datos de control de versiones y algoritmos de aprendizaje automático que identifican patrones sociales y riesgos ocultos en el código.
En conclusión, lo mejor sería una buena planeación desde el principio de la ejecución de un proyecto, esto para evitar la mayor cantidad de problemas que se presenten en su desarrollo, porque si o si por falta de tiempo, malas prácticas, mala implementación de patrones de desarrollo o errores comunes, se inyecta deuda técnica.
Pero esto no es del todo malo, ya que podemos aprender a trabajar y mejorar con base en errores comunes que se presentan y evitar posibles problemas similares en un futuro, no es que sea malo la deuda técnica, sino que se debe mantener vigilada y que en un periodo de tiempo aceptable se pague para evitar acumulación de errores en nuestro proyecto.
Autor: G. García
Referencias:
- Matalonga, S., Villar, A., & Nacimento, C. (2013). Deuda técnica: ¿Cuáles son los límites de la metáfora?. (Documento de Investigación nro. 10). Montevideo: Universidad ORT Uruguay. Facultad de Ingeniería. Recuperado de http://dspace.ort.edu.uy/handle/20.500.11968/2725
- Code smells. (s/f). Refactoring.Guru. Recuperado el 25 de mayo de 2022, de https://refactoring.guru/es/refactoring/smells
