Refactorización de código JavaScript: cuándo y cómo no romper el proyecto

Tu código funciona, pero eso no significa que sea bueno

Escribiste un script. Se ejecuta. Los clientes están contentos. Pero pasa un mes y miras con horror esa misma función que ha crecido hasta 200 líneas. En ella se mezclan peticiones a la API, manipulaciones del DOM y algo de magia con fechas. ¿Te suena familiar?

Bienvenido al mundo donde la refactorización de código JavaScript no es un capricho de perfeccionista, sino una necesidad vital. Si quieres que tu proyecto viva mucho tiempo y no se desmorone ante el primer cambio, este artículo es para ti.

Qué es la refactorización y qué no es

Empecemos por lo principal. La refactorización de código JavaScript es el proceso de cambiar la estructura interna de un programa sin alterar su comportamiento externo. No añades nuevas funciones, no corriges errores. Simplemente haces que el código sea más limpio, comprensible y fácil de mantener.

Muchos confunden la refactorización con la reescritura. Son cosas diferentes. Reescritura es cuando tiras el código viejo y escribes uno nuevo desde cero. La refactorización es evolución, no revolución. Cambias el código en pequeños pasos, verificando cada vez que nada se ha roto.

¿Cuándo se debe realizar la refactorización de JavaScript?

Aquí tienes algunas señales claras de que tu código está pidiendo ayuda a gritos:

\n
• La regla de tres. Si copias el mismo fragmento de código por tercera vez, es hora de extraerlo a una función separada.
\n
• Función monstruo. Una función de más de 30-40 líneas que no se puede leer de un vistazo.
\n
• "Números mágicos". Números como 86400000 o 42 dispersos por el código sin comentarios ni constantes.
\n
• Variables globales. Si tienes miedo de cambiar una variable porque no sabes dónde más se usa.
\n
• Pruebas. Si tienes miedo de hacer cambios porque no hay pruebas automáticas, esa es la primera señal de alarma.
\n

Pero también hay situaciones en las que la refactorización no es necesaria: antes de una fecha límite, en producción sin pruebas, o cuando el código está escrito a toda prisa para un prototipo que se desechará mañana.

Técnicas de refactorización de JavaScript: de lo simple a lo complejo

1. Extracción de función (Extract Function)

La técnica más popular y segura. Encuentras un fragmento de código que se puede agrupar y lo extraes a una función separada.

// ANTES de la refactorización\nfunction calculateInvoice(items) {\n  let total = 0;\n  for (let item of items) {\n    total += item.price * item.quantity;\n  }\n  let discount = 0;\n  if (total > 1000) {\n    discount = total * 0.1;\n  }\n  return total - discount;\n}\n\n// DESPUÉS de la refactorización\nfunction calculateSubtotal(items) {\n  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);\n}\n\nfunction calculateDiscount(total) {\n  return total > 1000 ? total * 0.1 : 0;\n}\n\nfunction calculateInvoice(items) {\n  const subtotal = calculateSubtotal(items);\n  const discount = calculateDiscount(subtotal);\n  return subtotal - discount;\n}\n

¿Qué cambió? Ahora cada función se encarga de una sola acción. Puedes reutilizar calculateSubtotal en otro lugar, y calculateDiscount es fácil de probar por separado.

2. Reemplazo de números mágicos por constantes

Nunca uses números "desnudos" en el código. En un mes, ni tú mismo recordarás qué significa 86400000.

// MALO\nif (Date.now() - lastLogin > 86400000) {\n  // solicitar nuevo inicio de sesión\n}\n\n// BUENO\nconst MILLISECONDS_IN_A_DAY = 24 * 60 * 60 * 1000;\nconst ONE_DAY_MS = 86400000; // o simplemente una constante legible\n\nif (Date.now() - lastLogin > ONE_DAY_MS) {\n  // solicitar nuevo inicio de sesión\n}\n

3. Simplificación de estructuras condicionales

Los complejos if-else anidados son el peor enemigo de la legibilidad. Usa retorno temprano (early return) y operadores ternarios.

<