Refactorización: mejora el código sin cambiar lo que hace

La refactorización es la práctica de reestructurar código existente para que sea más fácil de leer, cambiar y probar, sin cambiar lo que el software hace para sus usuarios. La haces en pasos pequeños, con una red de seguridad, mientras el producto sigue funcionando.

Soy un ingeniero brasileño que lleva siete años, desde 2019, construyendo y manteniendo productos web y móviles en uso, y el patrón que más veo es este: o los equipos nunca refactorizan hasta que todo duele, o intentan arreglarlo todo de una vez y rompen cosas. Esta guía cubre el camino intermedio.

¿Qué es la refactorización?

El término lo popularizó el libro Refactoring de Martin Fowler. La idea central es simple: una refactorización es una transformación pequeña que preserva el comportamiento observable. Renombrar una variable. Extraer un bloque de código a una función. Mover una función al módulo donde corresponde. Reemplazar una condicional anidada por una lógica más clara.

Cada uno de esos cambios deja el producto haciendo exactamente lo que hacía antes. Un cliente que navega por la app no nota la diferencia. El próximo desarrollador sí.

Lo que la refactorización no es

• No es corregir un bug. Corregir un bug cambia el comportamiento, a propósito.
• No es una funcionalidad nueva. Por la misma razón.
• No es un proyecto de rendimiento. Optimizar puede cambiar los tiempos y el uso de recursos, así que trátalo como una tarea aparte.
• No es una actualización de dependencias ni una migración de framework. A menudo requieren refactorizar antes, pero son cambios separados.

¿En qué se diferencia refactorizar de reescribir?

La refactorización conserva el sistema existente y lo mejora en pasos pequeños y publicables. La reescritura construye un sistema nuevo y hace el cambio más adelante. Ambas pueden arreglar una base de código desordenada, pero sus perfiles de riesgo son muy distintos.

La fila del comportamiento oculto es la parte que los fundadores subestiman. El código viejo suele contener años de decisiones silenciosas: un caso límite para un cliente, una regla de pago añadida después de un incidente. Una reescritura tiene que redescubrir todo eso. La refactorización lo mantiene intacto mientras limpias alrededor.

Cuando el problema es más grande que la estructura del código, como un stack al final de su vida útil, refactorizar no alcanza. Entonces la ruta más segura suele ser una migración incremental, en la que pones un switch delante del sistema viejo y mueves el tráfico pieza por pieza, en lugar de una reescritura big-bang. Así abordé la migración que lideré de una plataforma de postulaciones a empleos en producción, de un stack legado a uno nuevo, mientras la gente seguía usándola todos los días.

¿Cuándo vale la pena refactorizar y cuándo no?

La refactorización es una inversión y, como toda inversión, solo rinde si usas el resultado. Mi regla práctica: refactoriza el código que vas a tocar de nuevo pronto.

Normalmente vale la pena cuando

• Estás a punto de agregar una funcionalidad en un área difícil de entender. Límpiala primero, luego construye.
• La misma parte del código produce un bug tras otro.
• Cambios simples tardan mucho más de lo que deberían por una lógica enredada.
• Los desarrolladores nuevos se atascan siempre en los mismos archivos.
• Quieres agregar tests a código que hoy es imposible de probar.

Normalmente no vale la pena cuando

• El código es feo pero estable y nadie necesita cambiarlo. Déjalo en paz.
• La funcionalidad está a punto de eliminarse o reemplazarse.
• No tienes forma de verificar el comportamiento ni tiempo para construir esa red de seguridad. Refactorizar a ciegas es apostar.
• El objetivo es puramente estético, como ajustarse a una preferencia de estilo.

La pregunta que me hago es: ¿qué será más fácil el mes que viene gracias a este cambio? Si no puedo responder en una frase, lo salto.

¿Qué hace segura una refactorización: tests, pasos pequeños y revisiones?

La refactorización segura se apoya en tres hábitos. Funcionan juntos, y abandonar uno debilita a los otros.

1. Tests que fijan el comportamiento actual

Necesitas una forma de saber que el comportamiento no cambió. Si el código ya tiene buenos tests automatizados, ejecútalos después de cada paso. Si no los tiene, escribe primero tests de caracterización: tests que registran lo que el código hace hoy, aunque ese comportamiento sea raro. No dicen qué es lo correcto. Son una alarma.

Prioriza los flujos de dinero: checkout, facturación, registro, cualquier cosa donde un cambio silencioso cueste dinero o confianza de verdad. Como trabajé en el equipo de carrito y checkout de Total Wine & More, siempre empiezo por ahí. Si los tests automatizados todavía no son realistas, un checklist manual corto para esos flujos es mejor que nada.

2. Pasos pequeños, cada uno publicable

Haz un cambio, ejecuta las verificaciones, haz commit. Luego el siguiente. Un buen paso de refactorización es lo bastante pequeño como para describirlo en una sola línea y, si algo se rompe, puedes revertirlo sin perder un día de trabajo.

Para cambios más grandes, pon el nuevo camino detrás de una feature flag o mantén la función vieja junto a la nueva hasta que confíes en ella. Así puedes volver atrás rápido en lugar de depurar bajo presión.

3. Revisión que separa estructura de comportamiento

Mantén los commits y pull requests de refactorización separados del trabajo de funcionalidades. Así el revisor puede hacerse una sola pregunta: ¿este cambio toca solo la estructura? Revisar un pull request mezclado es mucho más difícil, y los bugs se esconden en la mezcla.

En mis proyectos con TypeScript me apoyo en las herramientas: las refactorizaciones del editor (renombrar, extraer, mover), los linters y un compilador estricto son más confiables que editar a mano.

¿Qué refactorizaciones rinden primero en un producto en crecimiento?

No necesitas técnicas exóticas. En los productos en los que he trabajado, un puñado de movimientos básicos aportó la mayor parte del valor.

1. Pon nombres honestos. Una función llamada process que en realidad valida y cobra una tarjeta es una trampa. Los buenos nombres son la documentación más barata.
2. Divide funciones y componentes enormes. Una sola función de 500 líneas es difícil de probar y difícil de cambiar. Extrae piezas con nombre y una sola responsabilidad cada una.
3. Elimina la duplicación cuando es real. Si la misma regla de negocio vive en tres lugares, tarde o temprano un cambio se olvidará de uno. No unas código que solo se parece por coincidencia.
4. Aísla las dependencias externas. Pon los proveedores de pago, los servicios de email y las APIs de terceros detrás de un wrapper delgado propio. Facilita las pruebas y abarata los cambios futuros.
5. Borra el código muerto. El código sin uso cuesta tiempo de lectura y esconde la lógica real. El control de versiones lo recuerda si lo necesitas de vuelta.
6. Saca las reglas de negocio de la UI y de las consultas a la base de datos. Las reglas en un lugar claro son más fáciles de probar y cambiar.

Fíjate en que ninguna de estas requiere un framework nuevo ni un gran plan. Además, sientan las bases para movimientos más grandes después. En Inovaula construí la v2 de la plataforma web y luego lideré al equipo, que alcanzó el flujo de entrega más estable que había tenido; en mi experiencia, hábitos pequeños y constantes como estos hacen que ese tipo de previsibilidad sea más fácil de lograr.

¿Cómo encajas la refactorización en un calendario de entregas?

El enfoque que mejor funciona no es un sprint dedicado a refactorizar. Esos se recortan la primera vez que se retrasa un plazo. En cambio, haz que la refactorización sea parte de cómo se construyen las funcionalidades.

• Prepara, luego cambia. Antes de agregar una funcionalidad, dedica un poco de tiempo a hacer que el área sea más fácil de cambiar. Luego agrega la funcionalidad. Incluye ambas cosas en la estimación.
• Déjalo un poco más limpio. Cuando toques un archivo por cualquier motivo, haz una pequeña mejora cerca. Se acumula sin necesidad de un proyecto.
• Mantén una lista corta. Anota las áreas problemáticas a medida que las encuentres, con una nota de por qué duelen. Cuando algo se convierta en un bloqueo, ya tendrás la evidencia.
• Limita en el tiempo los esfuerzos grandes. Si un área necesita una reestructuración real, acuerda un límite de antemano, entrégala por partes y detente cuando llegues al límite.
• Explícalo en términos de negocio. Vincula cada esfuerzo a un resultado: menos incidentes en el checkout, un onboarding más rápido para desarrolladores nuevos o menos riesgo antes de un lanzamiento.

Cuando un equipo que lidero está bajo mucha presión de plazos, igual protejo dos cosas: los tests en los flujos de dinero y las refactorizaciones pequeñas dentro del trabajo de funcionalidades. Las limpiezas más grandes pueden esperar a un momento más tranquilo.

Si la base de código es heredada y todavía no sabes qué es riesgoso, audítala antes de refactorizar nada. Cuando asumo una base de código, sigo este orden: primero los accesos, luego el build, luego los flujos de dinero, luego los riesgos. Solo entonces elijo los objetivos.

¿Quieres una segunda opinión sobre tu base de código?

Si estás decidiendo qué refactorizar en tu producto, o si necesita algo más que refactorización, escríbeme a me@filipeeduardo.dev con una breve descripción de la situación. Con gusto le echo un vistazo y te digo qué revisaría primero.