Documentos de Académico
Documentos de Profesional
Documentos de Cultura
(/digitalguide/)
Índice
1. ¿Por qué se habla de deuda técnica? (paginas-web/desarrollo-web/deuda-tecnica-explicada/#c291950)
2. El cuadrante de la deuda técnica: cuatro tipos de deuda (paginas-web/desarrollo-web/deuda-tecnica-explicada/#c291952)
3. ¿Qué origen puede tener la deuda técnica? (paginas-web/desarrollo-web/deuda-tecnica-explicada/#c291955)
4. Deuda técnica y desarrollo ágil de software (paginas-web/desarrollo-web/deuda-tecnica-explicada/#c291956)
5. ¿Qué efectos tiene la deuda técnica sobre el desarrollo de software? (paginas-web/desarrollo-web/deuda-tecnica-explicada/#c291957)
6. ¿Cómo se puede evitar la deuda técnica? (paginas-web/desarrollo-web/deuda-tecnica-explicada/#c291958)
En 1992, Ward Cunningham, programador y coautor del Manifiesto por el desarrollo ágil de software, introdujo la metáfora de la deuda técnica.
Con este concepto, Cunningham quería ilustrar la importancia que la refactorización (paginas-web/desarrollo-web/que-es-la-refactorizacion/) es
decir, la corrección regular del código, tiene para el software. Solo de esta forma es posible evitar que un software genere siempre mas deuda
por las crecientes deficiencias operativas y estructurales.
El término deuda también implica intereses, puesto que la deuda técnica es relevante para las empresas contratantes sobre todo desde el
punto de vista financiero. La deuda técnica no solo implica más esfuerzo y una menor productividad debido a las medidas de mantenimiento
posteriores, sino también más costes. Cuanto más descuida la dirección de un equipo el mantenimiento de una infraestructura o aplicación
informática defectuosa, más intereses genera la deuda y más caras resultan las correcciones del código.
Según Ward Cunningham, la deuda técnica se origina debido a deficiencias en el código que, por falta de tiempo o presupuesto, obligan a
adoptar una solución más rápida del problema, aunque deficiente. Un código escrito de manera minuciosa y exhaustiva es laborioso y requiere
mucho tiempo. Por este motivo, a veces los desarrolladores optan por un código sucio con el objetivo de ahorrar así tiempo y esfuerzo. Pero
este ahorro se paga con deuda.
Para Cunningham, este aspecto económico de la programación no es algo inusual o antinatural. En caso de que la deuda técnica no se
Digital Guide
compense mediante refactorización ni el código se optimice con regularidad, el desarrollo acabará por interrumpirse o detenerse debido a los
intereses metafóricos.
(/digitalguide/)
Martin Fowler, autor de Refactoring: Improving the Design of Existing Code, concretó la metáfora de Cunningham y subdividió la deuda técnica
en cuatro tipos, que representó en el cuadrante de la deuda técnica:
Deuda deliberada
Falta de Priorización de un suministro
tiempo/presupuesto rápido de software y
Refactorización compromiso de
descuidada refactorización
Deuda involuntaria
Falta de cualificación La refactorización constante
Documentación elimina errores y carencias de
insuficiente programación históricos y
Sobreingeniería ayuda a aprender de los
Anti patrones de diseño errores
Erosión de software
Según Cunningham y Fowler, la deuda técnica se puede generar tanto de manera deliberada como involuntaria. Puesto que la tecnología y la
programación incluyen revisiones y mejoras continuas, es prácticamente imposible evitar la hediondez del código y la erosión del código. El
software también envejece y, a falta de actualizaciones y refactorización, también genera deudas. En la mayoría de los casos, sin embargo, la
deuda técnica se debe a decisiones económicas o fallos de programación deliberados o involuntarios.
Aunque generalmente la deuda técnica siempre tiene los mismos efectos sobre el desarrollo de software, las causas pueden ser muy variadas.
Aquí se las presentamos:
Falta de gestión de calidad: los proyectos se desarrollan sin mecanismos de prueba, medición y control de calidad y generan deuda de
manera continua.
Presión económica: debido a las exigencias del cliente o a la presión de la competencia, se da prioridad a factores económicos y a un
desarrollo rápido en detrimento de la limpieza del código.
Falta de cualificación: los conocimientos técnicos del equipo de desarrollo no se corresponden con las exigencias de un código limpio y
elegante. La consecuencia es una hediondez de código o un código espagueti.
Documentación/comunicación insuficientes: el proceso de desarrollo transcurre sin documentar las ampliaciones y modificaciones del
código en paralelo. Además, las modificaciones del código no se registran ni comunican a los programadores posteriores. Las
posibilidades para la refactorización son limitadas o inexistentes.
Refactorización en diferido: la deuda técnica aceptada deliberadamente no se salda a corto plazo, puesto que la refactorización se pasa
por alto o se aplaza.
Desarrollo paralelo de aplicaciones: las fases de desarrollo que transcurren en paralelo, pero no se coordinan, provocan la acumulación
de deuda.
Código demasiado complejo: los párrafos de código son demasiado complicados o ilógicos. Las pequeñas modificaciones pueden
provocar más fallos y multiplicar la deuda. En el peor de los casos, también aquí se genera un código espagueti.
Digital
Procesos de desarrollo desestructurados: el desarrollo Guide
de aplicaciones comienza antes de que se definan y decidan un diseño o unos
procesos concretos.
(/digitalguide/)
Externalización del código: las fases de desarrollo se subcontratan y, durante el proceso posterior de unión, provocan errores en el código
que la dirección del equipo debe aceptar o ignorar.
Modificaciones repentinas en el proceso: debido a la falta de tiempo, las modificaciones repentinas en el código no se comprueban.
Ward Cunningham no solo definió la metáfora de la deuda técnica, sino que también es coautor y primer firmante del Manifiesto por el
desarrollo ágil de software (paginas-web/desarrollo-web/agile-development/). El objetivo de esta filosofía de desarrollo de software es fomentar
un desarrollo y publicación de aplicaciones más flexibles y productivos por medio de principios y axiomas.
En lugar de permanecer durante largos periodos de tiempo ligados a grandes proyectos, los equipos, más pequeños e independientes, se
esfuerzan por conseguir fases de trabajo más breves y publicaciones más rápidas de proyectos de menor envergadura, tales como aplicaciones,
partes de programas y actualizaciones.
El desarrollo ágil de software tiene como consecuencia que los equipos escriban y modifiquen un código en pequeños pasos y las fases de
trabajo se finalicen a más velocidad. Cuando la atención se centra en la rapidez y la productividad, aumenta el peligro de producir un código
sucio y, con ello, acumular deuda técnica. Sobre todo, cuando el desarrollo ágil de software no va de la mano con la refactorización, la deuda
aumenta de manera inevitable.
Los efectos de la deuda técnica se corresponden con los de los créditos en el sector financiero. Si la deuda no se reduce de manera puntual y
regular, se generan intereses, que se muestran en forma de desarrollo ralentizado, descenso en la productividad y aumento de los costes.
Por lo tanto, a los clientes les interesa acompañar el desarrollo a largo plazo con un proceso completo de gestión de calidad, para no tener que
pagar la rapidez y el ahorro en la producción y la publicación de los productos con costosas correcciones posteriores de errores o, incluso, un
parón en el desarrollo.
Debido a las nuevas tecnologías y la evolución en los planteamientos dentro del desarrollo de software, no es posible evitar la deuda técnica
por completo. De hecho, incluso se la acepta con el fin de publicar programas y aplicaciones de manera regular y rápida y no atar a los equipos
a proyectos de forma prolongada. No obstante, existen medidas preventivas para evitar o reducir la generación o el crecimiento de la deuda: