Refactor y deuda técnica
-
Upload
joan-sebastian-ramirez-perez -
Category
Software
-
view
205 -
download
0
Transcript of Refactor y deuda técnica
![Page 1: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/1.jpg)
Refactor y deuda técnica
Joan Sebastián Ramírez Pérez2015
![Page 2: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/2.jpg)
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.
![Page 3: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/3.jpg)
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.
![Page 4: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/4.jpg)
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
![Page 5: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/5.jpg)
“”
Saltarse una actividad necesaria y hacerla a destiempo lleva entre un x10 a un x100
de sobre tiempo
Fagan, IBM, 1976
![Page 6: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/6.jpg)
Deuda técnica de Philippe Kruchten
![Page 7: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/7.jpg)
Tomado de: http://www.slideshare.net/JavierGarzas/deuda-tecnica-slideshare?qid=2eba2bc2-2828-4c70-990d-206fe0affe33&v=qf1&b=&from_search=1
![Page 8: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/8.jpg)
Cuadrante deuda técnica de Fowler
![Page 9: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/9.jpg)
Cuadrante deuda técnica de Fowler
![Page 10: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/10.jpg)
“”
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
![Page 11: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/11.jpg)
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.
![Page 12: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/12.jpg)
¿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.
![Page 13: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/13.jpg)
¿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.
![Page 14: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/14.jpg)
¿Qué buscamos evitar con el refactor?
Perdida de la productividad escribiendo código en la medida que crece el sistema.
![Page 15: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/15.jpg)
![Page 16: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/16.jpg)
![Page 17: Refactor y deuda técnica](https://reader036.fdocumento.com/reader036/viewer/2022062400/587c712e1a28abd04e8b5ab3/html5/thumbnails/17.jpg)
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