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

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
• Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
• HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024