Poner orden en un front-end que creció demasiado rápido
El producto ganó, el código perdió. Un método práctico para recuperar el control de un front-end que creció a toda prisa — sin parar el roadmap y sin el temido rewrite.
Hay un tipo de código que solo tienen los productos de éxito. Salió rápido al mercado, conquistó clientes, y en cada sprint alguien enganchó una funcionalidad nueva a lo primero que pillaba. Tres años después el producto va estupendamente — y el front-end es una casa encantada. Cada desarrollador tiene un ala en la que se niega a entrar.
Si la escena te resulta familiar: enhorabuena, y mi más sentido pésame. Este es el método que aplico cuando un equipo me llama justo en ese momento.
Primero: ponerle nombre al problema real
"Deuda técnica" es un diagnóstico inútil: señala a todas partes y, por tanto, a ninguna. En la práctica, los front-ends que crecieron a toda prisa duelen casi siempre en los mismos sitios:
- El estado vive en todas partes. La caché del servidor, el store global, el estado de los componentes y la URL cuentan cada uno una verdad distinta.
- Los componentes hacen demasiado. El componente de 900 líneas que descarga datos, los transforma, pinta la interfaz y gestiona la navegación — importado en once sitios.
- Cada autor tiene su estilo. Tres maneras de llamar a la API, cuatro de gestionar errores, dos estructuras de carpetas compitiendo — según quién escribió cada parte y en qué año.
- Nadie se fía de un cambio. Faltan tests donde de verdad harían falta, y cada despliegue se convierte en un pequeño acto de valentía.
Antes de refactorizar nada, dedica una semana a medir: ¿dónde se concentran los bugs? ¿Qué ficheros se tocan en absolutamente todas las features? Ese mapa — frecuencia de cambio × densidad de defectos — te dice dónde está la palanca. Suelen ser 4–6 ficheros, no cuatrocientos.
Las reglas del juego
Nada de rewrite. Un rewrite cambia problemas que conoces por problemas que aún no conoces, y congela el roadmap mientras los vas redescubriendo. La empresa que financió tu crecimiento no va a financiar un año de "nada nuevo, pero por dentro está mucho mejor, prometido".
La regla del boy scout no es una estrategia. "Deja el código mejor de como lo encontraste" produce actos de orden aleatorios. La mejora tiene que seguir el mapa de la palanca, no el ánimo del desarrollador.
Cada paso llega a producción. Si un refactor no puede desplegarse por sí solo, es demasiado grande. Recórtalo hasta que pueda.
El método
1. Cortar la hemorragia
Antes de mejorar nada, deja de empeorarlo. Acuerda con tu equipo un único patrón de referencia para los cuatro grandes temas — obtención de datos, estado, gestión de errores, estructura de carpetas — y hazlo cumplir solo en el código nuevo, en las reviews y con reglas de lint. El código viejo, de momento, no se toca. Cuesta casi nada y divide de inmediato el código en "legacy" y "camino de salida".
2. Construir el camino asfaltado
Coge lo que tu equipo construye más a menudo — una pantalla de lista con detalle, un flujo con formulario — y crea la implementación de referencia: capa de API tipada, error boundaries, estados de carga, tests. No una página de wiki: código funcionando en el repositorio, que la gente copia. Un patrón que no sea más fácil de seguir que de ignorar será ignorado.
3. Estrangular por tráfico, no por estética
Ahora se recorre el mapa de la palanca. Los módulos con más cambios y más defectos se reconstruyen primero sobre el camino asfaltado — de uno en uno, cada uno desplegado a producción bajo la misma URL. El código feo que nadie toca se queda feo. Se lo ha ganado: funciona y no molesta a nadie. El refactor estético de código estable es la forma en que mueren los presupuestos de modernización.
4. Hacer visible la tendencia
Elige dos o tres números que todo el equipo pueda ver moverse: cobertura de tipos, tamaño del bundle, defectos por versión, tiempo hasta el merge. Publícalos cada mes. Un equipo que mira una línea de tendencia la defiende; uno que no la mira retrocede en un trimestre.
Cómo funciona en la vida real
En un gran e-commerce cuyo front-end lideré hicimos exactamente esto: estándares exigidos en review desde la primera semana, TypeScript estricto como camino asfaltado, y los componentes centrales del catálogo — la zona del código con más cambios de todas — reconstruidos de forma incremental mientras el tren de despliegues seguía saliendo cada semana. Sin congelar features, sin ramas monstruosas, y en dos trimestres el equipo era más rápido de forma medible, y más tranquilo. Lo segundo importa más de lo que parece: un equipo que deja de tenerle miedo a su propio código toma mejores decisiones en todo lo demás.
Los plazos, con honestidad
Para el front-end de un producto mediano, la recuperación es cuestión de trimestres, no de semanas — pero los resultados se notan pronto: la hemorragia se corta la primera semana, el camino asfaltado existe en un mes, y el primer módulo de alta palanca llega a producción poco después. Si alguien te promete un código transformado en tres semanas, te está describiendo una demo.
Trabajo como arquitecto de software con foco en front-end: modernizo productos que crecieron más rápido que su código, sin pararlos. Si tu front-end se ha convertido en la parte del roadmap que todos esquivan, hablemos: una llamada introductoria de 30 minutos es gratuita y suele aclarar mucho.