miércoles, 16 de enero de 2013

Que es la deuda técnica ?

Artículo perteneciente a la sección de calidad del código

Hola a todos,

Hoy toca explicar un concepto bastante curioso del mundo de la programación. La deuda técnica. Si habéis seguido los tutoriales del  blog seguramente ya habréis programado en pequeños proyectos y os habréis encontrado con fallos que os han hecho perder mucho tiempo en resolverlos. A medida que los proyectos son más grandes estos fallos y cuellos de botella se hacen cada vez peores, de más difícil solución y lo que es peor, es más complicado detectarlos.

En los años 60 aparecieron los primeros casos de deuda técnica pero no fue hasta 1992 que  Ward Cunningham le acuñó nombre. La deuda técnica no es más que hacer las cosas mal, no tiene más explicación.La deuda técnica no es sino una forma de llamar a la situación en la que se decide programar rápido y mal para llegar a una fecha de entrega sin pensar en que eso después puede acarrear muchos problemas (a veces sencillamente puede ser falta de motivación o falta de capacidad para elaborar una solución mejor, depende de los casos.)

Los síntomas más claros de que nuestro proyecto tiene deuda técnica son:
- Complejidad en la programación
- Cuando alguien tiene que aprender como funciona, cada vez cuesta más.
- Es más complicado añadir funcionalidades al código (de hecho, hay cosas que es imposible implementar)
- Es más complicado encontrar los bugs y en muchas ocasiones la resolución de bugs comporta nuevos bugs.
- Un análisis a fondo del código demuestra que la modularidad del código es peor de la imaginada y que es muy posible que una nueva implementación de funcionalidades implique un fallo en cascada de todo el sistema.


No obstante, no todo es malo, y aunque tengamos proyectos con deuda técnica, todo se puede salvar.
Los pasos para salvar el proyecto son:
1. Dejar de incluir código "malo": Es decir, tenemos código podrido en el proyecto, ok , asumamoslo  pero no por ello incluyamos más código destructivo.
2. No se ha de hacer un gran refactoring. Es decir, intentar cambiar todo el proyecto a un nuevo enfoque para eliminar toda la deuda que tengamos de una sola tacada normalmente tiene solo un resultado: la muerte del proyecto. Así murió el navegador Netscape, por si no os lo creeis.
3. Incluir auto-tests en el código. El desarrollo de código mediante TDD ayuda, sino es TDD, tests de compilación y/o funcionamiento, algo que permita asegurar que el hecho de tocar un trozo de código no nos destruye el funcionamiento del resto del producto.
4. Paciencia. Mucha paciencia. Cuando pides un préstamo al banco, tienes una deuda. Y la tienes que pagar mes a mes durante muchos años. Con la deuda técnica pasa lo mismo. Se ha de ir "limpiando" el código pernicioso poco a poco, asegurándonos que no rompemos el funcionamiento del proyecto y usando métricas que nos permitan verificar que realmente estamos mejorando la calidad del código.

Si detectas que estás en una situación de deuda técnica y que ninguno de estos pasos ayuda, plantéate seriamente cancelar el proyecto o reiniciarlo aprovechando la experiencia del error cometido. A veces es mejor empezar desde 0 cuando llevas el 20% del proyecto realizado que no cuando llevas el 95% hecho.

En próximos artículos iré ahondando más sobre este tema.

Espero que os haya gustado.

Si este artículo os ha sabido a poco y quereis aprender un poco más sobre el legacy code y la deuda ténica tal vez podeis echarle un ojo a alguno de estos libros:

Nos vemos

LordPakusBlog

0 comentarios :

Publicar un comentario

Entradas populares