En la vida de todo desarrollador de software, existe un rito de iniciación inevitable. Te asignan un proyecto urgente. El reloj corre, la fecha de entrega se acerca y la presión del cliente es asfixiante. Para cumplir con el plazo, empiezas a escribir código a toda velocidad: copias y pegas bloques enteros, anidas condicionales dentro de bucles interminables y creas variables con nombres rápidos como dato1, temp o x.
Al final del día, pulsas el botón de compilar y, milagrosamente, la aplicación funciona. El cliente está contento y tú respiras aliviado. Sin embargo, seis meses después, tu jefe te pide añadir una nueva funcionalidad a esa misma aplicación. Abres tu archivo de código fuente y un escalofrío te recorre la espalda. Las líneas se entrelazan de forma caótica, no recuerdas qué hace cada función y al intentar modificar una sola variable, tres módulos distintos de la aplicación dejan de funcionar.
Acabas de enfrentarte a tu propia creación: el temido Código Espagueti.
En la ingeniería de software profesional, que un programa funcione en el ordenador es solo el 50% del trabajo. El otro 50% consiste en que el código sea legible, mantenible y escalable por otros seres humanos. Para transformar un caos incomprensible en un sistema robusto, la industria utiliza una disciplina fundamental: la Refactorización. En este artículo descubriremos qué es exactamente, aprenderemos a detectar los «malos olores» en nuestro código y aplicaremos técnicas reales para limpiar nuestra lógica.
¿Qué es (y qué NO es) la Refactorización?
El término fue popularizado por el ingeniero de software Martin Fowler en su legendario libro Refactoring. La definición técnica es estricta: Refactorizar es el proceso de reestructurar el código informático existente sin cambiar su comportamiento externo.
Imagina que estás ordenando un armario desordenado. No estás comprando ropa nueva (eso sería añadir nuevas funcionalidades al software), ni estás tirando ropa a la basura (eso sería eliminar características). Simplemente estás doblando las camisetas, agrupando los pantalones y categorizando todo en cajones. Cuando terminas, el armario contiene exactamente la misma ropa que antes, pero ahora encontrar una prenda específica te lleva tres segundos en lugar de diez minutos.
Si al refactorizar tu código el programa empieza a hacer cosas nuevas o, peor aún, deja de hacer cosas que antes hacía bien, no estás refactorizando; estás reescribiendo o rompiendo el sistema.
Identificando al Enemigo: Los «Code Smells» (Malos Olores)
Antes de poder limpiar el código, necesitas saber dónde está la suciedad. En el argot del desarrollo, a los indicios de que un código está mal diseñado se les llama Code Smells (Malos olores). No son errores de compilación (el programa funciona), pero «huelen» a que en el futuro causarán problemas graves.
Los cuatro hedores más comunes en el código de un desarrollador júnior son:
- Funciones Dios (God Functions): Una función que ocupa 200 líneas de código y hace quince cosas distintas (valida al usuario, consulta la base de datos, calcula los impuestos y envía un correo electrónico). Rompe frontalmente el Principio de Responsabilidad Única (SRP), que dicta que una función debe hacer una sola cosa y hacerla perfectamente.
- Código Duplicado (Copy-Paste): Como vimos al hablar de los bucles, violar el principio DRY (Don’t Repeat Yourself). Si tienes la misma fórmula de cálculo de IVA copiada en cinco archivos distintos, el día que el gobierno suba el IVA tendrás que buscar y modificar el código en cinco sitios diferentes, asumiendo un riesgo enorme de olvidar alguno.
- Números Mágicos (Magic Numbers): Ver números literales flotando en medio de cálculos sin ninguna explicación. Por ejemplo:
precio_final = subtotal * 1.21 + 4.99. ¿Qué es 1.21? ¿Qué es 4.99? Para quien no escribió el código, son un misterio indescifrable. - Nombres de Variables Opacos: Utilizar nombres como
lista_usr,d,flagocalcularValores(). Obligan al lector a leer todo el código interior para adivinar qué significa esa variable.
El Arte de Limpiar: Caso Práctico de Refactorización
Vamos a ver cómo se aplica este proceso en el mundo real. Tenemos una función espagueti en Python que procesa una compra en una tienda online. Funciona perfectamente, pero huele muy mal.
El Código Espagueti (Antes)
Python
# Anti-patrón: Todo mezclado, variables opacas, números mágicos.
def procesar(u, cart):
if u != None:
if u.status == 1:
tot = 0
for i in cart:
tot = tot + i.p
# Aplicamos el descuento y el impuesto
if tot > 100:
tot = tot - (tot * 0.10)
tot = tot + (tot * 0.21) + 4.99
u.saldo = u.saldo - tot
print("Compra exitosa para " + u.n)
return True
else:
print("Error")
return False
else:
print("Error")
return False
En apenas 20 líneas, hemos violado casi todas las reglas del código limpio. Tenemos «Código en flecha» (múltiples if anidados), números mágicos (1, 0.10, 0.21, 4.99), nombres crípticos (u, cart, tot, p, n) y una función que hace demasiadas cosas.
El Código Limpio (Después de Refactorizar)
Vamos a aplicar tres técnicas fundamentales de refactorización:
- Cláusulas de Guarda (Early Returns): Para eliminar la anidación de los
if(como aprendimos en artículos anteriores). - Extracción de Constantes: Para dar nombre a los números mágicos.
- Nombres Descriptivos: Para que el código se lea como un libro en inglés/español.
Python
# Código Limpio, profesional y refactorizado
# 1. Extracción de Números Mágicos a Constantes (Fáciles de modificar en el futuro)
ESTADO_ACTIVO = 1
DESCUENTO_CLIENTE_VIP = 0.10
UMBRAL_DESCUENTO = 100.00
TASA_IMPUESTO_IVA = 0.21
COSTE_ENVIO_ESTANDAR = 4.99
def procesar_compra_cliente(usuario, carrito_compras):
# 2. Cláusulas de Guarda (Porteros de discoteca, evitan el Arrow Code)
if usuario is None:
print("Error: Usuario no encontrado.")
return False
if usuario.estado != ESTADO_ACTIVO:
print("Error: La cuenta de usuario está inactiva.")
return False
# 3. Lógica principal plana y con nombres legibles
subtotal = sum(item.precio for item in carrito_compras)
if subtotal > UMBRAL_DESCUENTO:
subtotal -= (subtotal * DESCUENTO_CLIENTE_VIP)
total_con_impuestos = subtotal + (subtotal * TASA_IMPUESTO_IVA)
precio_final = total_con_impuestos + COSTE_ENVIO_ESTANDAR
# 4. Finalización
usuario.saldo -= precio_final
print(f"Compra exitosa procesada para el cliente: {usuario.nombre}")
return True
El comportamiento de ambos programas es idénticamente matemático. Sin embargo, el segundo código es una obra de ingeniería mantenible. Si mañana el coste de envío sube a 5.99, cualquier programador júnior sabrá exactamente dónde cambiarlo en la línea de las constantes, sin tener que adentrarse en la lógica matemática.
Además, si quisiéramos llevar el principio de Responsabilidad Única al extremo, podríamos extraer el cálculo matemático de los impuestos y descuentos a una nueva función llamada calcular_precio_final(subtotal), dejando la función principal aún más limpia y delegando el cálculo a un módulo especializado. A esta técnica se le llama Extracción de Métodos.
La Red de Seguridad: Los Tests Unitarios
Existe una regla de oro en la industria del software: Nunca refactorices código que no tiene Pruebas Unitarias (Unit Tests).
Refactorizar sin pruebas automatizadas es el equivalente a caminar por una cuerda floja sobre un rascacielos sin una red de seguridad. Si cambias un signo + por un - o mueves una variable de sitio durante la refactorización, ¿cómo sabes que el código sigue calculando el precio exacto sin equivocarse ni un céntimo? Si tienes que abrir la aplicación y hacer la compra manualmente para comprobarlo, perderás horas de trabajo.
Los Tests Unitarios son pequeños programas que evalúan a tus programas. Antes de refactorizar el código espagueti original, un profesional escribe un test automático que dice: «Si le paso a esta función un carrito de 120€, el resultado final debe ser exactamente 135.67€».
Una vez que el test está escrito y pasa en verde (aprobado), puedes empezar a modificar y limpiar la función con total tranquilidad. Si en algún momento estropeas la matemática, el test automático se volverá rojo instantáneamente, avisándote de que tu refactorización acaba de romper la lógica de negocio.
Conclusión: La Regla del Boy Scout
Muchos desarrolladores ven la refactorización como una fase aislada del proyecto: «Escribiré el código rápido ahora, y el mes que viene pediré una semana de pausa a mi jefe para refactorizarlo». Esto es una mentira. El negocio nunca se detiene para dejarte limpiar tu código.
La refactorización no es un hito en un calendario; es un hábito diario, como lavarse los dientes. Los mejores arquitectos de software aplican lo que se conoce como La Regla del Boy Scout: «Deja el campamento siempre un poco más limpio de lo que te lo encontraste».
Si hoy te han asignado solucionar un pequeño error (un bug) en un archivo escrito hace dos años, no te limites a poner el parche y huir. Aprovecha que tienes el archivo abierto para renombrar esa variable oscura, extraer ese número mágico a una constante o romper esa Función Dios en dos funciones más pequeñas. Mediante estas pequeñas refactorizaciones diarias y continuas, el temido código espagueti de las aplicaciones corporativas se va alisando de forma orgánica, transformándose lentamente en un ecosistema robusto, profesional y listo para escalar hacia el futuro.
