Refactorización de código Swift: cuándo es necesaria y cómo hacerla correctamente

Tu código funciona, pero eso no es motivo para no tocarlo

Has escrito una aplicación, se ejecuta, los clientes están contentos, los builds no fallan. Parecería que puedes relajarte y dedicarte a nuevas funcionalidades. Pero dentro de la base de código hay un monstruo de Frankenstein: métodos de 300 líneas, copia y pega, lógica enredada y números mágicos esparcidos por todo el proyecto. Si alguna vez te has sorprendido pensando "mejor no tocar esta clase, o todo se romperá" — la refactorización de código Swift no es solo una recomendación para ti, sino una necesidad vital.

En este artículo analizaremos cuándo realmente vale la pena emprender la refactorización y cuándo es mejor dejar el código en paz. Te mostraré ejemplos concretos en Swift que podrás aplicar hoy mismo. Y sí, nada de rodeos — solo práctica.

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

Empecemos por lo básico. La refactorización de código Swift es el proceso de cambiar la estructura interna de un programa sin alterar su comportamiento externo. No agregas nuevas funciones, no arreglas bugs (aunque a menudo los encuentras en el camino). Simplemente haces el código más limpio, comprensible y fácil de mantener.

Es importante entender: refactorización ≠ reescribir desde cero. Si quieres tirar todo el proyecto y empezar de nuevo con SwiftUI y la arquitectura TCA — eso no es refactorización, es reescritura. Y la reescritura, como muestra la experiencia, termina en fracaso en el 80% de los casos.

Cuándo hacer refactorización de código Swift: tres señales claras

1. La Regla de Tres (Rule of Three)

Si copias el mismo fragmento de código por tercera vez — es una señal. No la segunda, sino precisamente la tercera. La primera vez está bien, resolviste el problema. La segunda vez ya es dudoso, pero se puede atribuir a las prisas. La tercera vez — ya está, escribe una solución generalizada.

// Mal: copia y pegafunc formatUserName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

func formatProductName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

// Bien: método unificadofunc formatDisplayName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

2. El "olor" de métodos largos

Si un método no cabe en la pantalla del teléfono — es un problema. En la comunidad Swift se acostumbra a orientarse a 15-20 líneas por método. Por supuesto, hay excepciones (cálculos complejos), pero en el 95% de los casos un método largo es señal de que está haciendo demasiado.

3. Las pruebas se convierten en un infierno

Cuando para probar una función necesitas simular 5 servicios, configurar la base de datos y leer un archivo del disco — es una bandera roja. La refactorización de código Swift debe hacer tu base de código más testeable. Si ahora escribir pruebas es doloroso — significa que la arquitectura pide cambios.

Ejemplos prácticos de refactorización en Swift

Veamos situaciones reales a las que se enfrenta todo desarrollador iOS.

Ejemplo 1: Eliminando números mágicos

Los números mágicos son literales numéricos cuyo valor no se entiende sin contexto. Hacen que el código sea frágil e ilegible.

// Antes de la refactorizaciónfunc calculateDiscount(price: Double) -> Double {    if price > 1000 {        return price * 0.15    } else if price > 500 {        return price * 0.1    } else {        return price * 0.05    }}

// Después de la refactorizaciónprivate struct DiscountConstants {    static let premiumThreshold: Double = 1000    static let standardThreshold: Double = 500    static let premiumRate: Double = 0.15    static let standardRate: Double = 0.10    static let basicRate: Double = 0.05}

func calculateDiscount(price: Double) -> Double {    switch price {    case _ where price > DiscountConstants.premiumThreshold:        return price * DiscountConstants.premiumRate    case _ where price > DiscountConstants.standardThreshold:        return price * DiscountConstants.s