Breve introducción a la Refactorización (Refactoring) (3/3). Aplicación

(Enlace a la parte 2 de este artículo: Breve introducción a la Refactorización (Refactoring) (2/3). Justificación)
En lo que refiere al proceso de refactorización, existen algunos consejos y buenas prácticas a tener en cuenta:
– No añadir funcionalidad mientras se refactoriza. La regla básica de la refactorización es no cambiar la funcionalidad del código o su comportamiento observable externamente. El programa debería comportarse exactamente de la misma forma antes y después de la refactorización. Si el comportamiento cambia entonces será imposible asegurar que la refactorización no ha estropeado algo que antes ya funcionaba.
– Un uso riguroso de las pruebas. No se debería comenzar un proceso de refactorización si no se dispone de un buen conjunto de pruebas. Las pruebas son necesarias porque permiten comprobar que una vez refactorizado el software mantiene su funcionalidad.
– Refactorizar en diferentes momentos del ciclo de vida. Se aconseja refactorizar antes de añadir nueva funcionalidad (haciendo más fácil añadirla) o después (simplificando el código una vez introducida), cuando se necesita reparar un error o al revisar el código.
– Usar los bad smells (“malos olores”). Los bad smells pueden ser una buena ayuda a la hora de detectar dónde aplicar refactorizaciones.
Por otro lado, hay que considerar que llevar a cabo la refactorización manual supondrá una tarea larga y tediosa. Tokuda y Batory presentaron un caso de estudio en el que se aplicaron 800 refactorizaciones a un programa de 500k líneas de código… y que llevo dos semanas de trabajo haciéndolo de manera manual y dos días de manera automatizada. Por ello, desde hace años se ha estado trabajando en herramientas de refactorización, siendo “Smalltalk Refactoring Browser” de 1999, desarrollada bajo del marco de la Tesis de Roberts, la que se considera primera herramienta de refactorización. Pero, sin embargo, aún hoy, el problema de automatizar la refactorización sigue siendo complejo, ya que aunque hay refactorizaciones que apenas necesitan analizar la estructura del software, como, por ejemplo, aquellas que se encargan de renombrar, pero la mayoría debe analizar y manipular el árbol del programa, y en ocasiones esto es complejo, por lo que aún queda camino por recorrer en la automatización de la refactorización.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
• Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
• Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024