Introducción a la deuda técnica
La deuda técnica es un término que describe el costo futuro que vendrá de elegir una solución fácil hoy en lugar de usar mejores prácticas que tardarían más tiempo en completarse.
Se eligió el término "deuda técnica" porque es similar a la deuda financiera. Es habitual que las personas en deuda financiera tomen decisiones que parezcan correctas o como la única opción en el momento, pero al hacerlo, aumenta el interés.
Cuanto más se acumule el interés, más difícil les resultará en el futuro y menos opciones tendrán más adelante. Con la deuda financiera, pronto el interés aumenta sobre el interés, creando un efecto de bola de nieve. De forma similar, la deuda técnica puede acumularse hasta el punto en que los desarrolladores pasan casi todo su tiempo solucionando problemas y realizando reprocesos, planeados o no planeados, en lugar de agregar valor.
Entonces, ¿cómo sucede?
La excusa más común es unas fechas límite. Cuando los desarrolladores se ven obligados a crear código rápidamente, a menudo tomarán accesos directos. Por ejemplo, en lugar de refactorizar un método para incluir una nueva funcionalidad, podría copiarlo para crear una nueva versión. A continuación, solo prueban el nuevo código y pueden evitar el nivel de prueba necesario si cambian el método original porque otras partes del código lo usan.
Ahora tienen dos copias del mismo código que deben modificarse en el futuro en lugar de una, y corren el riesgo de que la lógica sea diferente. Hay muchas causas. Por ejemplo, puede haber una falta de aptitudes técnicas y madurez entre los desarrolladores o sin una clara propiedad o dirección del producto.
Es posible que la organización no tenga estándares de codificación en absoluto, por lo que los desarrolladores ni siquiera sabían lo que deberían producir. Es posible que los desarrolladores no tengan claros los requisitos a seguir o que estén sujetos a cambios de requisitos de última hora.
Es posible que se retrase el trabajo de refactorización necesario. Es posible que no haya pruebas de calidad de código, manuales o automatizadas. Al final, solo hace que sea más difícil y difícil ofrecer valor a los clientes en un plazo de tiempo razonable y a un costo razonable.
La deuda técnica es una de las principales razones por las que los proyectos no cumplen sus fechas límite.
Con el tiempo, aumenta de la misma manera que la deuda monetaria. Las fuentes comunes de deuda técnica son:
- Falta de estilo y estándares de codificación
- Falta o un diseño deficiente de casos de prueba unitaria
- Omitir o no comprender los principios de diseño orientados a objetos
- Clases monolíticas y bibliotecas de código
- El uso mal planificado de la tecnología, la arquitectura y el enfoque (olvidando que todos los atributos del sistema, que afectan al mantenimiento, la experiencia del usuario, la escalabilidad y otros, deben ser considerados)
- 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 escribir código de autodocumentación (incluidos los nombres de clase, método y variable que son descriptivos o indican la intención)
- Utilizar atajos para cumplir con los plazos
- Dejar código inactivo en su lugar
Nota:
Con el tiempo, la deuda técnica debe devolverse. De lo contrario, la capacidad del equipo de corregir problemas e implementar nuevas características y mejoras tardará más tiempo y, finalmente, se convertirá en prohibitiva de costos.
Hemos visto que la deuda técnica agrega 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 reduce la productividad, frustra a los equipos de desarrollo, hace que el código sea difícil de entender y frágil, aumenta el tiempo para realizar cambios y validar esos cambios. El trabajo no planeado suele interferir con el trabajo planeado.
A largo plazo, también debilita la fuerza de la organización. La deuda técnica tiende a acumularse en una organización. Comienza a ser pequeño y crece con el tiempo. Cada vez que se realiza un hack rápido o se omiten las pruebas porque los cambios deben apresurarse, el problema se empeora y empeora. Los costos de soporte técnico aumentan y aumentan y, finalmente, surgen problemas graves.
Finalmente, la organización no puede responder a las necesidades de sus clientes de forma oportuna y rentable.
Medición automatizada para la supervisión
Una manera clave de minimizar la constante acumulación de deuda técnica es usar pruebas y evaluaciones automatizadas.
En las demostraciones siguientes, veremos una de las herramientas comunes que se usan para evaluar la deuda: SonarCloud. (La versión local original era SonarQube).
Hay otras herramientas disponibles y analizaremos algunas de ellas.
Más adelante, en el siguiente laboratorio práctico, verá cómo configurar Azure Pipelines para usar SonarCloud, comprender los resultados del 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 de código usa actualmente (si las hay)?
¿Qué le gusta o no le gustan las herramientas?