search
top

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.

Latest posts by Javier Garzás (see all)

Una respuesta to “Breve introducción a la Refactorización (Refactoring) (3/3). Aplicación

  1. Marta dice:

    Busque lo que busque en google relacionado con alguna duda me sale un post tuyo.
    Gracias por el material. Voy a empezar con refactoring html e iré tirando del hilo a ver qué concluyo.
    Una vez me encargaron una task: refactorizar la aplicación… Así de concreta la tarea. Empecé encapsulando funcionalidad y no pude seguir. A ver si estos libros me ayudan, ya por curiosidad, si me viese en otra tener más capacidad para abordar el problema.

Trackbacks/Pingbacks

  1. La deuda técnica. Todo el mundo debería saber que la mala calidad software al final se paga - Javier Garzás, sobre calidad software y otros temas relacionados - [...] Archivado en General en nov.22, 2012 por jgarzas La metáfora de la “deuda técnica” aplicada al desarrollo…

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top