Refactor y deuda técnica

Joan Sebastián Ramírez Pérez2015

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.

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.

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

“”

Saltarse una actividad necesaria y hacerla a destiempo lleva entre un x10 a un x100

de sobre tiempo

Fagan, IBM, 1976

Deuda técnica de Philippe Kruchten

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

Cuadrante deuda técnica de Fowler

Cuadrante deuda técnica de Fowler

“”

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

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.

¿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.

¿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.

¿Qué buscamos evitar con el refactor?

Perdida de la productividad escribiendo código en la medida que crece el sistema.

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