Refactoring en pasos pequeños y verificados

Objetivo

Hacer que el código existente sea más legible y más barato de modificar, demostrando paso a paso que su comportamiento observable no cambia.

Requisitos previos

La definición de Fowler: un refactoring es un cambio en la estructura interna del software que lo hace más fácil de entender y más barato de modificar sin cambiar su comportamiento observable. Esto presupone pruebas que fijen ese comportamiento. Si no existen, hay que escribir primero pruebas de caracterización: invocar el código con entradas representativas y fijar como resultado esperado las salidas actuales, aunque parezcan extrañas. Además, se necesita el catálogo de refactoring.com, con pasos con nombre como Extract Function, Inline Function, Move Function, Rename Variable o Introduce Parameter Object, y un conjunto de pruebas que se ejecute en segundos.

Pasos

1. Nombrar el estado objetivo y el code smell que se quiere eliminar (función larga, código duplicado, grupos de datos); anotar esa frase como borrador del mensaje de commit.
2. Aplicar un único refactoring con nombre y, siempre que sea posible, usar la automatización del editor, que se encarga de renombrar y extraer en todos los puntos de llamada.
3. Ejecutar las pruebas. Si fallan, hay que deshacer el paso (con el undo del editor o, si el último estado en verde está en un commit, con git restore .) en lugar de depurar hacia delante: el paso era demasiado grande o, en realidad, el comportamiento no está cubierto.
4. Tras cada grupo razonable de pasos en verde, hacer commit con un mensaje que empiece por refactor: y que no prometa ningún cambio de comportamiento.
5. Poner los cambios de comportamiento estrictamente en commits propios, antes o después. Quien revisa debe poder confiar en que un diff de refactoring no altera el comportamiento; así lo lee por estructura y no línea por línea.
6. Parar en cuanto desaparezca el smell. La generalización especulativa («seguro que esto lo necesitaremos») es un nuevo smell, no un refactoring.

Resultado esperado

Una serie de commits pequeños, todos en verde y cada uno revisable en minutos, que juntos dan la estructura prevista, y un conjunto de pruebas que por el camino se ha vuelto más completo.

Límites y base de verificación

Las pruebas solo protegen lo que cubren; el tiempo de ejecución, el consumo de memoria y la concurrencia pueden cambiar sin que nadie lo note. Las reestructuraciones que cruzan los límites de módulos exigen la misma disciplina y además un plan, por ejemplo el patrón Strangler Fig. La definición y el catálogo siguen las páginas citadas; la secuencia de pasos es una propuesta sin mediciones.