Introducción a la deuda técnica
La deuda técnica es un término que describe el coste futuro en el que se incurrirá por elegir una solución fácil, en lugar de adoptar prácticas más adecuadas debido a que tardarían más en completarse.
El término deuda técnica se eligió por su comparación con la deuda financiera. Es habitual que las personas con deuda financiera tomen decisiones que parecen adecuadas o la única opción en ese momento, pero, al hacerlo, aumentan los intereses.
Cuantos más intereses se acumulen, más se dificulta el futuro y más opciones secundarias estarán disponibles posteriormente. Con la deuda financiera, los intereses pronto hacen aumentar los intereses, de modo que se crea un efecto de bola de nieve. De forma similar, la deuda técnica puede acumularse hasta el punto de que los desarrolladores pasen casi todo su tiempo resolviendo problemas y rehaciendo el trabajo, planeado o no, en lugar de agregar valor.
Por lo tanto, ¿cómo ocurre?
La excusa más común son las fechas límite ajustadas. Cuando los desarrolladores se ven obligados a crear código rápidamente, suelen tomar atajos. Por ejemplo, en lugar de refactorizar un método para incluir una nueva funcionalidad, vamos a copiarlo para crear una versión. A continuación, solo pruebo el nuevo código y puedo evitar el nivel de prueba necesario si cambio el método original, ya que otras partes del código lo usan.
Ahora tengo dos copias del mismo código que necesito modificar en el futuro en lugar de una, y corro el riesgo de que la lógica diverja. Hay muchas causas. Por ejemplo, puede haber una falta de conocimientos técnicos y madurez entre los desarrolladores o quizás no haya una dirección o propiedad clara del producto.
Es posible que la organización no tenga estándares de codificación. Por lo tanto, los desarrolladores ni siquiera sabían lo que debían producir. Puede que los desarrolladores no tengan requisitos precisos que cumplir. También pueden estar sujetos a cambios de última hora en los requisitos.
Es posible que el trabajo de refactorización necesario se retrase. Puede que no haya pruebas de calidad del código, manuales ni automatizadas. Al final, se dificulta cada vez más la entrega de valor a los clientes en un plazo de tiempo y a un coste razonables.
La deuda técnica es uno de los motivos principales por los que no se cumplen las fechas límite de los proyectos.
Con el tiempo, aumenta de forma muy similar a como lo hace la deuda financiera. Algunos motivos comunes de deuda técnica son los siguientes:
- Falta de estilo y estándares de codificación.
- Diseño deficiente de los casos de prueba unitaria o ausencia de él.
- Principios de diseño orientado a objetos ignorados o no comprendidos.
- Bibliotecas de código y clases monolíticas.
- Mala previsión del uso de la tecnología, la arquitectura y el enfoque. (Se olvida de que se deben tener en cuenta todos los atributos del sistema, que afectan al mantenimiento, la experiencia del usuario, la escalabilidad, etc.).
- Código de ingeniería excesiva (agregar o crear código que no es necesario, agregar código personalizado cuando las bibliotecas existentes son suficientes o crear capas o componentes que no son necesarios).
- Comentarios y documentación insuficientes.
- No se escribe código autodescriptivo (se incluyen los nombres de clase, método y variable que son descriptivos o indican intención).
- Se recurre a atajos para cumplir las fechas límite.
- El código no alcanzado se deja en el lugar.
Nota:
Con el tiempo, la deuda técnica se debe devolver. De lo contrario, la capacidad del equipo para corregir problemas e implementar nuevas características y mejoras llevará más tiempo y, finalmente, tendrá un coste prohibitivo.
Se ha visto que la deuda técnica agrega un conjunto de problemas durante el desarrollo y hace que sea mucho más difícil agregar valor adicional al cliente.
Tener deuda técnica en un proyecto debilita la productividad, frustra a los equipos de desarrollo, hace que el código sea difícil de entender y frágil y aumenta el tiempo necesario para realizar y validar cambios. Con frecuencia, el trabajo no planeado entorpece el trabajo planeado.
A largo plazo, también debilita la fortaleza de la organización. La deuda técnica tiende a avanzar sigilosamente en una organización. Empieza a pequeña escala y crece con el tiempo. Cada vez que se realiza un ataque rápido o se evitan las pruebas porque es necesario realizar los cambios con rapidez, el problema aumenta y empeora. Los costes de soporte técnico son cada vez mayores y, de manera sistemática, surge un problema grave.
Finalmente, la organización no puede responder a las necesidades de sus clientes de forma rápida y rentable.
Medida automatizada para la supervisión
Una forma clave de minimizar la adquisición constante de deuda técnica es usar pruebas y evaluaciones automatizadas.
En las demostraciones siguientes, se presentará una de las herramientas comunes que se usan para evaluar la deuda: SonarCloud. (La versión local original era SonarQube).
Hay otras herramientas disponibles, algunas de las cuales se analizarán.
Más adelante, en el siguiente laboratorio práctico, obtendrá información sobre cómo configurar la instancia de Azure Pipelines para usar SonarCloud, comprender los resultados de los análisis y, por último, cómo configurar perfiles de calidad para controlar los conjuntos de reglas que usa SonarCloud al analizar los proyectos.
Para obtener más información, consulte SonarCloud.
Revisión:
Azure DevOps se puede integrar con una amplia gama de herramientas existentes que se usan para comprobar la calidad del código durante las compilaciones.
¿Qué herramientas de calidad del código usa actualmente (si usa alguna)?
¿Qué le gusta o no le gusta de las herramientas?