¿Refactorizar o reescribir desde cero? Cómo decidir
Para CTO y desarrolladoresDecisiones de CTO
Filip PapranecFundador de Digitaliko
Refactorizar es cambiar el código para mejorar su estructura sin cambiar lo que hace el software. Refactorizar o reescribir desde cero es una decisión sobre cuántos meses de roadmap está dispuesto a detener. Refactorizar en pasos pequeños suele ganar, porque el producto sigue generando ingresos mientras lo hace.
Reescribir desde cero tiene sentido en tres casos: el código hace lo incorrecto, no es suyo o funciona sobre una tecnología sin soporte. A continuación encontrará una tabla de decisión y una forma de refactorizar sin detener el roadmap.
La mayor parte de nuestro código la escribe la IA. Un senior revisa cada cambio y responde de producción. Durante años desarrollamos un SaaS que usaban a diario más de 60 000 personas. Nunca se reescribió desde cero. Cambió mediante cambios pequeños y revisados, directamente en el producto en marcha.
¿Por qué una gran reescritura casi siempre sale más cara de lo que parece?
Una reescritura parece limpia porque el código nuevo todavía no tiene historia. Pero esa historia la necesita. Detrás de cada condición extraña del código antiguo suele haber la queja de alguien.
Los motivos más habituales por los que una reescritura se encarece:
Reescribir desde cero
- Pierde las correcciones. El código antiguo guarda años de pequeños arreglos, y los clientes vuelven a encontrar los errores.
- Paga dos sistemas. Hasta que la reescritura esté lista, el antiguo sigue necesitando mantenimiento y funciones.
- El roadmap se detiene. Ventas espera funciones, y el sistema nuevo empieza haciendo menos.
- El objetivo se mueve. Cuando la reescritura lo alcanza, el sistema antiguo ya tiene funciones nuevas.
Ninguno de estos costes
Refactorizar en pasos pequeños
- El producto sigue funcionando y generando ingresos.
- Los clientes no notan nada.
- Cada cambio se puede revertir.
- Las funciones nuevas salen junto con la refactorización.
Cuándo refactorizar y cuándo reescribir: tabla de decisión
| Situación | Qué recomendamos | Por qué |
|---|---|---|
| El código hace lo correcto, pero es difícil de cambiar | Refactorizar | Quiere conservar el comportamiento y cambiar solo la forma del código. |
| No hay tests | Primero tests, luego refactorizar | Sin tests no sabe qué ha roto. |
| Una parte frena todo lo demás | Sustituir esa parte, refactorizar el resto | Un módulo detrás de una interfaz estable es manejable. |
| El código hace lo incorrecto, el negocio ha cambiado | Reescribir esa parte | No tiene sentido conservar un comportamiento que no quiere. |
| El código no es suyo o no tiene acceso a él | Sistema nuevo y traslado de datos | No hay nada que refactorizar. |
| La tecnología no tiene soporte ni parches de seguridad | Migración gradual | Muévalo parte por parte, no todo de una vez. |
| Nadie en el equipo entiende el código | Primero entender, después decidir | Un código que nadie entiende no es motivo para reescribirlo. Es motivo para escribir tests. |
Fíjese en la última fila. «Nadie lo entiende» es el argumento más habitual para reescribir. También es el peor. Un equipo nuevo que no entiende el código antiguo lo reescribirá sin las correcciones que contiene.
Una reescritura es además la venta adicional más fácil. Con más frecuencia basta con continuar módulo a módulo y empezar por la parte más arriesgada, como el inicio de sesión y los permisos.
¿Cómo refactorizar sin detener el roadmap?
01
Tests del comportamiento actual
Primero describa lo que hace hoy el sistema, errores incluidos. Solo después cámbielo.
02
Pasos pequeños en el flujo normal
Ninguna rama que pase un mes sin fusionarse. Cada cambio pasa por revisión y CI.
03
Refactorice donde construye una función
El código que nadie toca en un mes puede esperar.
04
Construya la parte nueva junto a la antigua
Cambie de forma gradual hasta que pueda apagar la antigua.
05
Un CI que de verdad detenga un mal cambio
Un check verde sin tests no demuestra nada.
Aquí la IA hace la parte lenta y aburrida. Tests del comportamiento existente, mover código, renombrar. Un senior decide qué cambia y en qué orden. Las reglas que le damos a la IA para esto las describimos en Reglas para el código de IA en un equipo.
Cuando tienes tests, refactorizar es fácil.
Sin tests ni revisión, la IA solo hace crecer su deuda técnica más deprisa. Por eso decimos que un agente es un modelo más un harness. El harness es lo que detiene un mal cambio.
¿Cuándo es reescribir desde cero la decisión correcta?
Cuando el código no es suyo. Si el sistema original no le pertenece, no hay nada que refactorizar: se construye uno nuevo y los datos se trasladan.
Una reescritura sigue el mismo orden. Primero los datos y entender lo que el sistema hace de verdad. Después pantalla a pantalla, no todo en un día.
Repase seis puntos antes de decidir. Marque lo que se cumple en su sistema:
El cuarto punto es el que más pesa. Si el código hace lo correcto, solo que mal, refactorice.
Cuándo no lo recomendamos
- Tiene un senior que conoce el sistema y dispone de tiempo para ello. Refactorice usted mismo. La tabla de arriba es suficiente.
- El sistema se apaga dentro de unos meses. No invierta en código que se acaba. Invierta en trasladar los datos.
¿Quiere decidirlo con alguien que lo hace a diario?
Un senior se incorpora a su repositorio y a sus pull requests desde el primer día. Primero tests, después cambios en pasos pequeños, y el roadmap sigue avanzando. Así trabajamos como desarrollador externo para equipos de producto.
Cuéntenos qué parte del código le está frenando. Le respondemos en un plazo de dos días hábiles con algunas preguntas sobre su trabajo. Después acordamos qué hacemos primero.
Si prefiere hablar antes, reserve una llamada introductoria de 15 minutos.
¿Qué parte de su código le gustaría más tirar, y por qué?
En resumen
- Refactorice cuando el código hace lo correcto, pero mal. Reescriba cuando hace lo incorrecto o no es suyo.
- Una gran reescritura cuesta el roadmap, las correcciones y dos sistemas a la vez.
- Primero tests del comportamiento actual, después pasos pequeños en el flujo normal.
- Incluso una reescritura va parte por parte, nunca todo de una vez.
Preguntas frecuentes
¿Cuándo conviene refactorizar y cuándo reescribir desde cero?
Refactorice cuando el código hace lo correcto, pero es difícil de cambiar. Reescriba cuando hace lo incorrecto, el código no es suyo o la tecnología ha perdido el soporte. Incluso entonces, reescriba por partes, no todo de una vez.
¿Se puede refactorizar sin tests?
Se puede, pero es una apuesta. Primero escriba tests del comportamiento actual, errores incluidos. Solo después cambie el código. Sin tests, del error se entera por un cliente.
¿Cuánto dura una refactorización?
No tiene un final fijo, y está bien así. Se hace de forma continua en los pull requests habituales, donde ya está trabajando. Un proyecto de refactorización aparte que dura meses casi nunca termina.
¿Ayuda la IA a refactorizar?
Sí, con la escritura de tests, el movimiento de código y el renombrado. Decidir qué cambiar y en qué orden sigue siendo tarea de un senior. Sin tests ni revisión, la IA solo hace que los errores lleguen antes.
Pregunte a una IA sobre este artículo
La IA también tiene en cuenta nuestros otros artículos y la experiencia de proyectos reales.
ChatGPTClaudePerplexity
