Deuda técnica: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| 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''': | |||
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. | *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. | ||