Este documento discute la deuda técnica y el refactor. Explica que la deuda técnica surge cuando se desarrolla software rápidamente sin enfocarse en la calidad, lo que genera costos a largo plazo. El refactor es la forma de pagar esta deuda mediante la mejora del diseño del código sin cambiar su funcionalidad. También advierte que la deuda técnica debe pagarse rápidamente para evitar que sus intereses se disparen.

1. Refactor y deuda técnica
Joan Sebastián Ramírez Pérez
2015

2. Diseño emergente
• Cuando se desarrolla con metodologías ágiles el diseño va creaciendo de la
mano con las funcionalidades.
• Adaptar este crecimiento implica cambios en el diseño del código para
soportar este crecimiento.
• Estos cambios los hacemos a través del refactor.

3. Un desarrollo con mala calidad, obtiene beneficios a corto
plazo. Sin embargo esto puede generar deudas cuyos
intereses se disparen, se alarguen o incluso sean imposibles
de pagar.

4. Deuda técnica
• “Poca deuda técnica acelera el desarrollo, siempre que se pague con prontitud.”
Ward Cunningham, OOPSLA 1992
• “El peligro viene de la deuda que no se paga. Cada minuto que pasamos con código
no del todo correcto se incrementan los intereses” Ward Cunningham, OOPSLA
1992
• “Muchos confunden la deuda técnica con la idea de que se puede hacer código malo
con la idea de mejorarlo después” Ward Cunningham, YOUTUBE 2009
• “La capacidad de mejorar depende de haber preparado el código para poder
refactorizarlo” Ward Cunningham, YOUTUBE 2009

5. “
”
Saltarse una actividad necesaria y hacerla a destiempo
lleva entre un x10 a un x100 de sobre tiempo
Fagan, IBM, 1976

6. Deuda técnica de Philippe Kruchten

7. Tomado de: http://www.slideshare.net/JavierGarzas/deuda-tecnica-slideshare?qid=2eba2bc2-2828-4c70-990d-
206fe0affe33&v=qf1&b=&from_search=1

8. Cuadrante deuda técnica de Fowler

9. Cuadrante deuda técnica de Fowler

10. “
”
My experience is that, in software, the “good mess” is
only good up to a few days, definitely less than a week.
Henrik Kniberg, 2013

11. Refactor
• Es una transformación del código que no altera su funcionalidad pero si
altera su diseño.
• Es el mecanismo que tenemos para pagar la deuda técnica o para inyectar
calidad a nuestro código.

12. ¿Cuándo hacer refactor?
• Cuando detectamos malos olores en el código (lo que vimos en código
limpio).
• Cuando identificamos código duplicado.
• Cuando tenemos métodos muy grande (más de 20 líneas).
• Cuando tenemos clases muy grandes.
• Cuando un método tiene muchos parámetros.
• Cuanto identificamos comentarios en el código que dan señales de mal olor.

13. ¿Qué buscamos con el refactor?
• Transformar código ya escrito.
• Mantener el comportamiento de la aplicación, es decir, las funcionalidades.
• Mejorar la calidad del código.
• Mejorar la mantenibilidad de la aplicación.

14. ¿Qué buscamos evitar con el refactor?
Perdida de la productividad escribiendo código en la medida que crece el sistema.

17. Bibliografía
• P. Kruchten, R. Nord, and I. Ozkaya, “Technical debt: from metaphor to
theory and practice” IEEE Software, vol. 29(6), pp. 18-21, 2012.
• http://www.slideshare.net/JavierGarzas/deuda-tecnica-
slideshare?qid=2eba2bc2-2828-4c70-990d-
206fe0affe33&v=qf1&b=&from_search=1