Deuda técnica: Difference between revisions
No edit summary |
No edit summary |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
'''Deuda técnica''' es un neologismo empleado en el sector profesional TIC para describir la deuda de trabajo que se adquiere al producir código pobre, incumpliendo prácticas aconsejadas para el desarrollo de software. | |||
==Descripción== | |||
Los proyectos que actúan de esta forma, normalmente para atajar los tiempos de entrega adquieren una "deuda técnica", cuyos "intereses" se tendrán que acabar pagando, y supondrán mayor cuantía cuanto más tiempo pase. | |||
La deuda técnica suele materializarse en las siguientes formas: | La deuda técnica suele '''materializarse en las siguientes formas:''' | ||
* Documentación escasa, incompleta o inservible. | * Documentación escasa, incompleta o inservible. | ||
* Errores. | * Errores. | ||
| Line 7: | Line 9: | ||
* Arquitectura no escalable. | * Arquitectura no escalable. | ||
* Rigidez para actualizar a nuevas tecnologías o plataformas. | * Rigidez para actualizar a nuevas tecnologías o plataformas. | ||
==Origen y evolución== | |||
El término deuda técnica surge de una analogía utilizada por Ward Cunningham en 1992 en la que realiza la equivalencia entre un desarrollo de software que presentase determinadas carencias debido, generalmente, a la necesidad de realizar una entrega temprana, con la petición de un crédito financiero. | El término deuda técnica surge de una analogía utilizada por Ward Cunningham en 1992 en la que realiza la equivalencia entre un desarrollo de software que presentase determinadas carencias debido, generalmente, a la necesidad de realizar una entrega temprana, con la petición de un crédito financiero. | ||
Esta analogía ha sido ampliamente extendida ya que de igual forma que dicho crédito permitiría obtener liquidez a corto plazo a costa de generar unos intereses a liquidar durante un período de tiempo prolongado, las carencias introducidas durante el desarrollo del software proporcionan un beneficio a corto plazo (la entrega a tiempo de una versión del software) pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado sumado a un esfuerzo extra (los intereses), es decir, dichas carencias generarán una deuda técnica con los mismos aspectos negativos que los intereses del crédito financiero solicitado. | Esta analogía ha sido ampliamente extendida ya que de igual forma que dicho crédito permitiría obtener liquidez a corto plazo a costa de generar unos intereses a liquidar durante un período de tiempo prolongado, las carencias introducidas durante el desarrollo del software proporcionan un beneficio a corto plazo (la entrega a tiempo de una versión del software) pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado sumado a un esfuerzo extra (los intereses), es decir, dichas carencias generarán una deuda técnica con los mismos aspectos negativos que los intereses del crédito financiero solicitado. | ||
==Clasificación== | |||
Las deudas técnicas se pueden clasificar en: | |||
*'''Advertidas o inadvertidas.''' Si se atiende al reconocimiento o no de la deuda en el momento en que esta se da. | |||
*'''Prudentes o imprudentes.''' Si se atiende a la realización o no de un análisis de costo frente a beneficios. | |||
===Ejemplos=== | |||
A pesar de los tipos de deuda técnica y de que cada equipo tendrá que atender sus propias carencias durante el desarrollo de sus proyectos de software, a continuación se listan algunos ejemplos típicos de deudas técnicas: | |||
*Errores conocidos y no solucionados. | *Errores conocidos y no solucionados. | ||
*Mejoras en el código no implementadas. | *Mejoras en el código no implementadas. | ||
*Insuficientes pruebas o pruebas de mala calidad. | *Insuficientes pruebas o pruebas de mala calidad. | ||
*Documentación desactualizada, incompleta o inexistente. | *Documentación desactualizada, incompleta o inexistente. | ||
==El diario de deuda técnica== | |||
Es una herramienta que permite conocer la deuda técnica advertida, acumulada en cualquier momento del proyecto. | |||
Una opción muy extendida para llevar este tipo de diarios es utilizar las listas de tareas que habitualmente incorporan los entornos de desarrollo, las cuales escanean automáticamente el código en busca de comentarios con etiquetas en un formato particular y que, a partir de los hallazgos encontrados, generan un lista. Habitualmente, los entornos de desarrollo suelen aceptar las siguientes '''etiquetas''': | |||
*'''FIXME:''' permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior. | |||
*'''NOTE:''' permite indicar el funcionamiento interno de código o posibles dificultades que no están documentadas. | |||
Una opción muy extendida para llevar este tipo de diarios es utilizar las listas de tareas que habitualmente incorporan los entornos de desarrollo, las cuales escanean automáticamente el código en busca de comentarios con etiquetas en un formato particular y que, a partir de los hallazgos encontrados, generan un lista. Habitualmente, los entornos de desarrollo suelen aceptar las siguientes etiquetas: | *'''TODO:''' indica posibles mejoras a realizar en un futuro más o menos próximo. | ||
*'''XXX, KLUDGE, KLUGE o HACK:''' cualquiera de ellos advierte de código ineficiente, poco elegante o incluso insondable, pero que, sin embargo, funciona. | |||
*FIXME: permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior. | |||
*NOTE: permite indicar el funcionamiento interno de código o posibles dificultades que no están documentadas. | |||
*TODO: indica posibles mejoras a realizar en un futuro más o menos próximo. | |||
*XXX, KLUDGE, KLUGE o HACK: cualquiera de ellos advierte de código ineficiente, poco elegante o incluso insondable, pero que, sin embargo, funciona. | |||
Para evitar el riesgo de que estas anotaciones se acumulen con el tiempo (o lo que es lo mismo, de que la deuda técnica se acumule) puede resultar útil incluir la fecha al comentario asociado a la etiqueta para facilitar su seguimiento. Además, también puede resultar interesante anotar el número de veces que esa porción de código ha provocado algún tipo de problema. | Para evitar el riesgo de que estas anotaciones se acumulen con el tiempo (o lo que es lo mismo, de que la deuda técnica se acumule) puede resultar útil incluir la fecha al comentario asociado a la etiqueta para facilitar su seguimiento. Además, también puede resultar interesante anotar el número de veces que esa porción de código ha provocado algún tipo de problema. | ||
Con toda esta información será posible determinar, en cada momento, la cantidad de deuda técnica que acumula un proyecto para determinar, así mismo, cuando ha llegado el momento de detenerse a resolver cada uno de los problemas de los que se compone. | Con toda esta información será posible determinar, en cada momento, la cantidad de deuda técnica que acumula un proyecto para determinar, así mismo, cuando ha llegado el momento de detenerse a resolver cada uno de los problemas de los que se compone. | ||
==Véase también== | |||
*[[Modelo original de Scrum para desarrollo de software]]. | |||
*[[Crisis del software]]. | |||
[[Category:Glosario de términos]] | [[Category:Glosario de términos]] | ||
Latest revision as of 12:10, 12 January 2024
Deuda técnica es un neologismo empleado en el sector profesional TIC para describir la deuda de trabajo que se adquiere al producir código pobre, incumpliendo prácticas aconsejadas para el desarrollo de software.
Descripción
Los proyectos que actúan de esta forma, normalmente para atajar los tiempos de entrega adquieren una "deuda técnica", cuyos "intereses" se tendrán que acabar pagando, y supondrán mayor cuantía cuanto más tiempo pase.
La deuda técnica suele materializarse en las siguientes formas:
- Documentación escasa, incompleta o inservible.
- Errores.
- Ausencia o deficiente control de versiones.
- Arquitectura no escalable.
- Rigidez para actualizar a nuevas tecnologías o plataformas.
Origen y evolución
El término deuda técnica surge de una analogía utilizada por Ward Cunningham en 1992 en la que realiza la equivalencia entre un desarrollo de software que presentase determinadas carencias debido, generalmente, a la necesidad de realizar una entrega temprana, con la petición de un crédito financiero.
Esta analogía ha sido ampliamente extendida ya que de igual forma que dicho crédito permitiría obtener liquidez a corto plazo a costa de generar unos intereses a liquidar durante un período de tiempo prolongado, las carencias introducidas durante el desarrollo del software proporcionan un beneficio a corto plazo (la entrega a tiempo de una versión del software) pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado sumado a un esfuerzo extra (los intereses), es decir, dichas carencias generarán una deuda técnica con los mismos aspectos negativos que los intereses del crédito financiero solicitado.
Clasificación
Las deudas técnicas se pueden clasificar en:
- Advertidas o inadvertidas. Si se atiende al reconocimiento o no de la deuda en el momento en que esta se da.
- Prudentes o imprudentes. Si se atiende a la realización o no de un análisis de costo frente a beneficios.
Ejemplos
A pesar de los tipos de deuda técnica y de que cada equipo tendrá que atender sus propias carencias durante el desarrollo de sus proyectos de software, a continuación se listan algunos ejemplos típicos de deudas técnicas:
- Errores conocidos y no solucionados.
- Mejoras en el código no implementadas.
- Insuficientes pruebas o pruebas de mala calidad.
- Documentación desactualizada, incompleta o inexistente.
El diario de deuda técnica
Es una herramienta que permite conocer la deuda técnica advertida, acumulada en cualquier momento del proyecto.
Una opción muy extendida para llevar este tipo de diarios es utilizar las listas de tareas que habitualmente incorporan los entornos de desarrollo, las cuales escanean automáticamente el código en busca de comentarios con etiquetas en un formato particular y que, a partir de los hallazgos encontrados, generan un lista. Habitualmente, los entornos de desarrollo suelen aceptar las siguientes etiquetas:
- FIXME: permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior.
- NOTE: permite indicar el funcionamiento interno de código o posibles dificultades que no están documentadas.
- TODO: indica posibles mejoras a realizar en un futuro más o menos próximo.
- XXX, KLUDGE, KLUGE o HACK: cualquiera de ellos advierte de código ineficiente, poco elegante o incluso insondable, pero que, sin embargo, funciona.
Para evitar el riesgo de que estas anotaciones se acumulen con el tiempo (o lo que es lo mismo, de que la deuda técnica se acumule) puede resultar útil incluir la fecha al comentario asociado a la etiqueta para facilitar su seguimiento. Además, también puede resultar interesante anotar el número de veces que esa porción de código ha provocado algún tipo de problema.
Con toda esta información será posible determinar, en cada momento, la cantidad de deuda técnica que acumula un proyecto para determinar, así mismo, cuando ha llegado el momento de detenerse a resolver cada uno de los problemas de los que se compone.