1 / 18

Refactoring de aplicaciones legacy

Refactoring de aplicaciones legacy. Alejandra Garrido CONICET – LIFIA UNLP – CAETI UAI Proyecto CAETI: “El refactoring como práctica fundamental para la comprensión, restructuración, y actualización de aplicaciones legacy” http://uaicel.uai.edu.ar/gruporefactoring/inicio.aspx. Big Ball of Mud.

morey
Download Presentation

Refactoring de aplicaciones legacy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Refactoring de aplicaciones legacy Alejandra Garrido CONICET – LIFIA UNLP – CAETI UAI Proyecto CAETI: “El refactoring como práctica fundamental para la comprensión, restructuración, y actualización de aplicaciones legacy” http://uaicel.uai.edu.ar/gruporefactoring/inicio.aspx

  2. Big Ball of Mud • Querríamos tener arquitecturas de software elegantes, diseños que usen patrones y código flexible y reusable. • En realidad tenemos toneladas de “spaghetti code”, con poca estructura, ilegible, intocable. • Es una pesadilla, pero sin embargo subsiste. ¿Por qué? • “Big Ball of Mud”. Brian Foote and Joe Yoder. Pattern Languages of Programs 4. Addison-Wesley 2000. Alejandra Garrido - CIITI VIII - Rosario 2010

  3. Patrones del Big Ball of Mud • Comienza siendo “Throwaway code” que se instala y persiste, simplemente porque funciona • Cambios de requerimientos y agregado de funcionalidad como un “Piecemeal growth” continuo corroe las mejoras arquitecturas • Dejamos un Façade alrededor de lo que no queremos mostrar o tocar, “Sweeping it under the rug” Alejandra Garrido - CIITI VIII - Rosario 2010

  4. Aplicaciones Legacy • Desarrolladas durante años • Muchos programadores involucrados • Costosas • Imprescindibles • Escaso mantenimiento • Sin tests de unidad[Feathers] Alejandra Garrido - CIITI VIII - Rosario 2010

  5. Fortran • Fortran I→ II→ IV→ 66→ 77→ 90→ 95→ 2003→ 2008 • Nueva versión para finales de este año • Algunos usuarios en Inglaterra: • Meteorological Office • Ministry of Defence • universidades, laboratorios de investigación • instituciones científicas • industria financiera • Se estima que hay varias miles de organizaciones en Europa usando aplicaciones Fortran. Fuente: “Fortran - a language with a past and a future” www.bcs.org Alejandra Garrido - CIITI VIII - Rosario 2010

  6. ¿Cómo manejar el cambio? • Un mal diseño no es grave, hasta que hay que hacer cambios • No podemos prevenir los cambios • El problema no es el cambio sino nuestra incapacidad de manejarlo Alejandra Garrido - CIITI VIII - Rosario 2010

  7. Refactoring • Univ. of Illinois at Urbana-Champaign (UIUC) • Bill Opdyke, "Refactoring Object-Oriented Frameworks". PhD Thesis. 1992. • Surge la 1ra. herramienta de refactoring: Refactoring Browser para Smalltalk. • Transformación que preserva el comportamiento Alejandra Garrido - CIITI VIII - Rosario 2010

  8. Refactoring by Fowler • Proceso de cambiar la estructura interna del software mejorando la organización, legibilidad, adaptabilidad y mantenibilidad del código luego que ha sido escrito • que NO altera el comportamiento externo del sistema, • que mejora su estructura interna • Catálogo de refactorings • Proceso manual Alejandra Garrido - CIITI VIII - Rosario 2010

  9. Proceso de Refactoring • Implica • Eliminar duplicaciones • Simplificar lógicas complejas • Clarificar códigos • A través de cambios pequeños • Hacer muchos cambios pequeños es mas fácil y más seguro que un gran cambio • Cada pequeño cambio pone en evidencia otros cambios necesarios • Testear después de cada cambio Alejandra Garrido - CIITI VIII - Rosario 2010

  10. Automatización del Refactoring • Refactoring manual es muy costoso • Refactorings automáticos deben ser: • lo suficientemente potentes para manejar mejoras en el diseño • lo suficientemente restrictivos de manera depreservar el comportamiento Alejandra Garrido - CIITI VIII - Rosario 2010

  11. Seguridad y utilidad • Seguridad en la preservación del comportamiento brinda confianza • Un refactoring “seguro” para un programa puede no mejorar su diseño • Incluso aplicar refactorings arbitrariamente puede corromper el diseño • Una herramienta de refactoring debe asegurar que preserva el comportamiento pero no puede asegurar utilidad (mejoras en el diseño) Alejandra Garrido - CIITI VIII - Rosario 2010

  12. Photran – IDE para Fortran • Fortran 77 a 2003 • Open source • Syntax highlighting • Outline view • Interactive debugger • CVS support • Refactoring engine http://www.eclipse.org/photran/ Alejandra Garrido - CIITI VIII - Rosario 2010

  13. Extract Procedure Refactoring • Mueve sentencias a una • nueva subrutina y reemplaza las sentencias por una llamada a la subrutina, pasando las variables locales como parámetro. • Seleccionar sentencias • Elegir del menú Refactor -> Extract Procedure • Ingresar el nombre Alejandra Garrido - CIITI VIII - Rosario 2010

  14. Abordaje del BBoM • Los refactorings se hacen en pequeños pasos, pero en un BBoM los cambios necesarios son enormes • Diferente granularidad de refactorings • Orden de aplicación de refactorings • Orden generalizable? • Relación con el testing Alejandra Garrido - CIITI VIII - Rosario 2010

  15. Catalogar, sugerir • Catálogo de refactorings para código legacy • C refactoring [Garrido 2000] • www.fortranrefactoring.com.ar • Incorporar herramientas parasugerir refactorings: • ¿Qué métricas pueden ayudar a sugerir? • ¿Es práctico incorporar herramientas de ánalisis? • ¿Son útiles las herramientas gráficas? Alejandra Garrido - CIITI VIII - Rosario 2010

  16. Conclusiones • Resulta interesante estudiar cómo se puede adecuar la técnica de refactoring para permitir la actualización de una aplicación legacy, de manera de poder ingresarla posteriormente a un proceso ágil de continuo mantenimiento • Tener una herramienta que provee la infraestructura necesaria para el refactoring automático es un gran beneficio • Página del proyecto:http://uaicel.uai.edu.ar/gruporefactoring/inicio.aspx Alejandra Garrido - CIITI VIII - Rosario 2010

  17. Referencias • Brian Foote and Joseph Yoder. “Big Ball of Mud”. Pattern Languages of Program Design 4. Addison-Wesley, 2000. • William Opdyke. “Refactoring Object-Oriented Frameworks". PhD Thesis. UIUC. 1992. • Alejandra Garrido. “Software Refactoring Applied to C Programming Language”. MS Thesis. UIUC. 2000. • Martin Fowler. “Refactoring. Improving the design of existing code”. Addison-Wesley, 1999. • Joshua Kerievsky. “Refactoring to Patterns”. Addison Wesley, 2004. • Michael Feathers. “Working Effectively with Legacy Code”. Prentice Hall. 2005. Alejandra Garrido - CIITI VIII - Rosario 2010

  18. Muchas gracias! Alejandra Garrido alejandra.garrido@lifia.info.unlp.edu.ar

More Related