El reencuentro con el pasado
Hace un par de semanas me pasó algo que a todos nos termina ocurriendo tarde o temprano. Estaba buscando un fragmento de lógica para un proyecto nuevo y me acordé de que ya había resuelto algo parecido en una aplicación que construí hace unos tres años. Era una herramienta de gestión interna que hice para un pequeño negocio local, mi primer proyecto serio como freelance. Con toda la ilusión del mundo, abrí el repositorio en VS Code y, madre mía, casi me da un síncope de programador.
La arrogancia del "yo" actual
Mi primera reacción fue de puro horror. Al ver ese código, mi cerebro empezó a gritar: "¿Pero quién escribió este desastre?". Había funciones de trescientas líneas, variables con nombres tan descriptivos como data2 o aux, y una jerarquía de componentes que parecía un plato de espaguetis volcado sobre el teclado. En ese momento, poseído por una mezcla de orgullo y perfeccionismo técnico, decidí que no podía dejar eso así. Me propuse refactorizarlo todo. "En un fin de semana lo tengo listo y limpio", me dije a mí mismo con una ingenuidad que hoy me da hasta ternura.
Lo que empezó como una limpieza de cara rápida se convirtió en una bajada a los infiernos del desarrollo. Empecé a borrar cosas, a modularizar, a meter TypeScript donde antes solo había un any gigante, y de repente, todo dejó de funcionar. Lo que yo veía como "código feo" resultó ser un ecosistema delicado de parches y soluciones ingeniosas que resolvían problemas de los que yo ya ni me acordaba.
Cuando el "código feo" me dio una bofetada de realidad
A medida que intentaba "arreglar" el desastre, me di cuenta de una gran verdad: ese código, por muy mal que se viera ahora, llevaba tres años funcionando sin dar un solo error en producción. Tres años. Al intentar reescribir una lógica de filtrado especialmente enrevesada, descubrí que mis IFs anidados no eran producto del descuido, sino de un montón de casos borde que el cliente me había ido pidiendo sobre la marcha.
Ahí fue cuando la humildad me golpeó de frente. Mi yo de hace tres años no era un mal desarrollador; era un desarrollador que estaba resolviendo problemas reales con las herramientas y el conocimiento que tenía en ese momento. Ese código "sucio" era el testimonio de horas de pelea contra bugs, de llamadas a deshoras para solucionar problemas del servidor y de una comprensión profunda de las necesidades del usuario final, algo que yo, en mi afán de limpieza estética, había ignorado por completo.
¿Por qué le tenemos tanto miedo al código antiguo?
A veces nos obsesionamos con las últimas tendencias, con el Clean Code llevado al extremo y con tener el repositorio más elegante de GitHub. Pero nos olvidamos de que nuestra labor principal no es escribir poesía en sintaxis de JavaScript, sino crear soluciones que aporten valor. El código perfecto que nunca llega a producción no vale nada. El código "feo" que ayuda a una persona a gestionar su negocio cada día, lo vale todo.
Me di cuenta de que muchas veces queremos refactorizar no por necesidad técnica, sino por nuestro propio ego. Nos molesta ver que antes no sabíamos tanto como ahora. Queremos borrar el rastro de nuestra propia evolución porque nos avergüenza. Pero, ¿sabes qué? Si ves tu código de hace tres años y no te dan ganas de llorar un poco, es que no has aprendido nada en todo este tiempo. Esa vergüenza es, en realidad, el indicador más claro de tu crecimiento profesional.
Lo que he aprendido (y por qué cerré la pestaña de refactor)
Al final, después de pasarme todo el sábado rompiendo cosas, tomé la decisión más sensata: git checkout . y cerré el proyecto. Entendí que refactorizar por el simple hecho de que algo no se ve "bonito" es una pérdida de tiempo y recursos, a menos que haya un problema real de rendimiento o mantenibilidad que lo justifique.
Aprendí que el código es un organismo vivo que refleja un momento específico del tiempo. He aprendido a respetar más mis versiones pasadas. Si ese código cumplió su función y permitió que el cliente estuviera contento y que yo cobrara mi factura, entonces era buen código. No era perfecto, pero era eficaz.
// Lo que yo quería escribir ahora:
const processOrder = (order) => order.items.reduce((acc, curr) => acc + curr.price, 0);
// Lo que mi yo de hace 3 años escribió:
function total(pedido) {
let t = 0;
for(let i=0; i
Al ver el ejemplo de arriba, el reduce es más elegante, sí. Pero el bucle for con ese comentario me recordó un cambio de última hora que salvó una campaña de rebajas. Si lo hubiera cambiado sin pensar, habría roto el sistema de contabilidad del cliente.
Reflexiones finales
Mi consejo para cualquiera que se encuentre en esta situación es simple: sé amable con tu yo del pasado. No reescribas solo para sentirte mejor desarrollador hoy. Si algo funciona, respétalo. Estudia por qué se hizo así antes de juzgarlo. Y sobre todo, valora la funcionalidad por encima de la estética técnica innecesaria. El desarrollo de software es una carrera de fondo y cada línea de código feo que escribiste fue un escalón necesario para llegar a donde estás ahora. Al final, lo que importa no es lo limpio que esté el código en tu pantalla, sino el impacto que ese código tiene en el mundo real.