Refatoração de código Swift: quando é necessária e como fazer corretamente

Seu código funciona, mas isso não é motivo para não mexer nele

Você escreveu um aplicativo, ele funciona, os clientes estão satisfeitos, os builds não quebram. Parece que você pode relaxar e se dedicar a novas funcionalidades. Mas por dentro da base de código — um monstro de Frankenstein: métodos com 300 linhas, copia e cola, lógica confusa e números mágicos espalhados por todo o projeto. Se você já se pegou pensando "é melhor não mexer nessa classe, senão tudo quebra" — a refatoração de código Swift para você não é apenas uma recomendação, mas uma necessidade vital.

Neste artigo, vamos analisar quando realmente vale a pena se dedicar à refatoração e quando é melhor deixar o código em paz. Mostrarei exemplos concretos em Swift que você poderá aplicar ainda hoje. E sim, sem enrolação — apenas prática.

O que é refatoração e o que ela não é

Vamos começar pela base. Refatoração de código Swift é o processo de alterar a estrutura interna de um programa sem alterar seu comportamento externo. Você não adiciona novas funcionalidades, não corrige bugs (embora frequentemente os encontre pelo caminho). Você simplesmente torna o código mais limpo, compreensível e fácil de manter.

É importante entender: refatoração ≠ reescrever do zero. Se você quer jogar todo o projeto fora e começar de novo com SwiftUI e arquitetura TCA — isso não é refatoração, é reescrita. E reescrever, como a experiência mostra, em 80% dos casos termina em fracasso.

Quando fazer refatoração de código Swift: três sinais certeiros

1. Regra de Três (Rule of Three)

Se você copia o mesmo trecho de código pela terceira vez — isso é um sinal. Não na segunda, mas exatamente na terceira. A primeira vez — ok, você resolveu o problema. A segunda vez — já é duvidoso, mas pode ser atribuído à pressa. A terceira vez — pronto, escreva uma solução genérica.

// Ruim: copia e colafunc formatUserName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

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

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

2. "Cheiro" de métodos longos

Se o método não cabe na tela do celular — isso é um problema. Na comunidade Swift, é comum orientar-se por 15-20 linhas por método. Claro, existem exceções (cálculos complexos), mas em 95% dos casos, um método longo é um sinal de que ele está fazendo demais.

3. Testar se torna um inferno

Quando para testar uma função você precisa mockar 5 serviços, configurar um banco de dados e ler um arquivo do disco — isso é uma bandeira vermelha. A refatoração de código Swift deve tornar sua base de código mais testável. Se agora escrever testes é doloroso — significa que a arquitetura está pedindo mudanças.

Exemplos práticos de refatoração Swift

Vamos ver situações reais que todo desenvolvedor iOS enfrenta.

Exemplo 1: Eliminando números mágicos

Números mágicos são literais numéricos cujo valor não é compreensível sem contexto. Eles tornam o código frágil e ilegível.

// Antes da refatoraçãofunc calculateDiscount(price: Double) -> Double {    if price > 1000 {        return price * 0.15    } else if price > 500 {        return price * 0.1    } else {        return price * 0.05    }}

// Depois da refatoraçãoprivate 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