Todo desarrollador conoce esa sensación: Abrís un proyecto que escribiste hace tres o cuatro años y lo primero que pensás es:
"Esto hay que tirarlo todo y empezar de nuevo."
El código parece desordenado. Las dependencias quedaron viejas. El framework ya no está de moda o es obsoleto. Y, por supuesto, hoy lo harías mucho mejor.
La tentación de hacer un rewrite completo aparece tarde o temprano en casi todos los proyectos. El problema es que la mayoría termina consumiendo meses de trabajo para llegar exactamente al mismo lugar... o incluso a uno peor.
Después de varios años desarrollando aplicaciones web aprendí que modernizar un proyecto no consiste en cambiar todas las tecnologías. Consiste en tomar mejores decisiones.
De hecho, hace poco, migré una aplicación de Node.js a Vite para convertirla de una app web a una aplicación de escritorio que pudiera, eventualmente, convertirse en un Producto. Incluso intenté hacer este cambio manteniendo Node.js... Y a eso me refiero con "mejores decisiones"... Vite se lleva mejor con Tauri y es más cómodo para una app que se ejecuta en local y no tiene que levantar un servidor de Node para funcionar. Y no tuve que reescribir toda la App desde cero, simplemente fui migrando de a módulos. (Más detalles de esta aplicación próximamente)
Estas son algunas de las reglas que intento seguir cada vez que me toca poner al día una aplicación.
1. No reescribas por aburrimiento
La primera pregunta nunca debería ser: "¿Cómo hago una versión nueva?"
La pregunta correcta es: "¿Qué problema estoy intentando resolver?"
- ¿La aplicación es lenta?
- ¿Es difícil de mantener?
- ¿Tiene problemas de seguridad?
- ¿O simplemente te da vergüenza el código que escribiste hace cinco años?
Muchas veces el proyecto funciona perfectamente y el único problema es que hoy programás mejor que cuando lo empezaste. Eso es una buena noticia, no una excusa para empezar de cero.
2. Medí antes de optimizar
Hay una frase clásica en ingeniería de software:
Lo que no se mide, no se puede mejorar.
Antes era común medir tiempos con funciones como microtime(). Hoy tenemos herramientas muchísimo más completas.
Lighthouse, Chrome DevTools, React Profiler, Web Vitals o cualquier analizador de bundles pueden mostrar exactamente dónde está el cuello de botella.
Muchas veces descubrís que el problema no es donde imaginabas. Y otras veces descubrís que... en realidad no había ningún problema.
3. Eliminá dependencias antes de agregar nuevas
Con los años los proyectos empiezan a acumular librerías.
Una para las fechas.
Otra para hacer peticiones HTTP.
Otra para copiar texto.
Otra para manejar URLs.
Otra para generar IDs.
Y cuando te querés acordar tenés cientos de paquetes instalados para resolver problemas que hoy el navegador ya sabe hacer por sí solo.
Cada dependencia adicional implica:
- más peso para descargar;
- más superficie para bugs;
- más vulnerabilidades;
- más cosas que mantener.
La mejor dependencia suele ser la que nunca necesitaste instalar.
4. Aprovechá las APIs modernas del navegador
Hace diez años necesitábamos una librería para prácticamente todo. Hoy los navegadores incorporan herramientas excelentes:
- Fetch API
- Clipboard API
- Intersection Observer
- Resize Observer
- AbortController
- URL API
- Intl
- Web Share
Antes de agregar otra dependencia, preguntate si el navegador ya no resuelve ese problema. La respuesta muchas veces es "sí".
5. Separá la lógica del framework
Los frameworks cambian: AngularJS dio paso a Angular. Backbone desapareció. Vue, React, Svelte, Solid, Astro... todos seguirán evolucionando.
La lógica de negocio, en cambio, debería sobrevivir a cualquiera de ellos. Cuanto menos dependa tu código del framework elegido, más fácil va a ser migrarlo el día de mañana.
Los frameworks son herramientas. No deberían convertirse en el corazón de tu aplicación.
6. Optimizá la experiencia, no solamente el código
Es fácil obsesionarse con ahorrar unos pocos milisegundos.
Pero mientras discutimos si una función tarda dos milisegundos menos, el usuario sigue esperando cuatro segundos viendo un spinner.
Muchas veces mejora mucho más la percepción de velocidad implementar:
- carga progresiva;
- lazy loading;
- skeleton screens;
- caché inteligente;
- interfaces optimistas.
La aplicación no necesita ser perfecta. Necesita sentirse rápida.
7. El mejor JavaScript es el que nunca escribiste
Durante años la conversación giró alrededor del HTML y del CSS. Hoy el verdadero problema suele ser el exceso de JavaScript.
Cada línea adicional implica más código para descargar, analizar, ejecutar y mantener.
No todo necesita hidratarse. No todo necesita un framework. No todo necesita convertirse en un componente.
Reducir JavaScript suele mejorar el rendimiento mucho más que cualquier microoptimización.
8. Automatizá todo lo repetitivo
Si hacés la misma tarea más de dos veces, probablemente debería automatizarse.
Hoy existen herramientas excelentes para eso:
- ESLint
- Prettier
- GitHub Actions
- Husky
- pruebas automáticas
- integración continua
La computadora nunca se cansa, nunca se olvida y nunca tiene un mal día. Dejá que haga el trabajo repetitivo mientras vos resolvés problemas interesantes.
9. Documentá las decisiones, no el código
Los comentarios que explican qué hace una función suelen quedar obsoletos rápidamente.
En cambio, hay algo mucho más valioso para documentar:
¿Por qué tomaste determinada decisión?
¿Por qué elegiste Firestore en lugar de PostgreSQL?
¿Por qué no usaste Server Side Rendering?
¿Por qué decidiste mantener una API REST en lugar de GraphQL?
Dentro de seis meses probablemente entiendas el código. Lo que no vas a recordar es el motivo por el cual lo escribiste así.
10. Modernizá de forma incremental
Uno de los errores más comunes es intentar construir una "versión 2.0" durante un año entero. Mientras tanto, la aplicación original sigue necesitando mantenimiento. Los usuarios siguen esperando mejoras. Y el proyecto nuevo nunca termina de estar listo.
Siempre que sea posible, modernizá por partes:
- Reemplazá una pantalla.
- Después otra.
- Después otra más.
El usuario apenas notará el cambio y el riesgo será muchísimo menor.
Bonus: la IA no arregla una mala arquitectura
Las herramientas de inteligencia artificial son impresionantes: Escriben código, encuentran errores, generan documentación y aceleran muchísimo el desarrollo... Pero también tienen una limitación importante.
Si la arquitectura del proyecto es mala, la IA simplemente va a producir más código siguiendo esa misma arquitectura.
No reemplaza el criterio. No reemplaza el diseño. No reemplaza las buenas (o malas) decisiones.
Es una herramienta extraordinaria, si, pero sigue necesitando un buen arquitecto detrás del teclado.
Conclusión
Hace quince años el desafío era ahorrar memoria, reducir consultas SQL u optimizar servidores mucho más limitados que los actuales. Hoy el mayor enemigo suele ser otro: la complejidad.
Dependencias innecesarias, capas de abstracción, herramientas que se superponen y proyectos cada vez más difíciles de entender.
Modernizar una aplicación no significa usar el framework más nuevo ni seguir la última moda. Significa dejar el proyecto un poco mejor de como lo encontraste.
Porque al final del día, el mejor código no es el más moderno... Es el que alguien —incluido vos dentro de dos años— todavía puede entender.