Muletas em programação — o que são, causas e quando são justificadas

O que é uma “muleta” em programação

Uma muleta (crutch) é uma solução de software que funciona, mas é feita “apressadamente”: resolve um problema específico, mas não elimina sua causa, não segue a arquitetura do projeto e pode quebrar com as menores mudanças no ambiente. A metáfora é precisa — como uma muleta real, esse código ajuda a “andar”, mas não cura a “perna.”

Desenvolvedores “escoram com muletas” bugs, incompatibilidades de versão, peculiaridades de plataforma e requisitos urgentes do cliente. Uma muleta típica é uma muleta condicional: se iOS 15, adicione um espaçamento; se Huawei, esconda o botão. Essas verificações se multiplicam e transformam o código em um “bolo de camadas” de ramificações de plataforma e versão.

As muletas vêm em diferentes escalas: de uma única linha com uma condição de muleta a um módulo wrapper inteiro que “corrige” o comportamento de uma biblioteca. É importante entender que uma muleta nem sempre é má: nas mãos certas, é uma ferramenta que permite lançar um produto no prazo. O problema começa quando a muleta permanece no código para sempre.

Por que as muletas aparecem: causas e contexto

A principal razão para o aparecimento de muletas é o conflito entre a solução ideal e as restrições reais do projeto. O desenvolvedor sabe como fazer corretamente, mas o tempo, o dinheiro ou as limitações técnicas o impedem. Como resultado, surge uma solução de compromisso que “simplesmente funciona.”

Vejamos quatro razões principais pelas quais os desenvolvedores recorrem conscientemente a muletas. Compreender essas razões ajuda a tratar as muletas não como um erro, mas como uma ferramenta pragmática que precisa ser gerenciada.

Prazos

A razão mais comum. O lançamento é amanhã, o bug se reproduz apenas em um modelo específico, e corrigi-lo arquitetonicamente levaria duas semanas. Uma muleta condicional leva uma hora e resolve o problema. Após o lançamento, a equipe promete voltar e reescrever corretamente. “Nada é mais permanente do que uma solução temporária” — é exatamente sobre essas muletas.

Incompatibilidade de versão

A biblioteca A exige Android 12, mas seu aplicativo suporta Android 10. A solução é escrever um wrapper que verifica a versão do SO e seleciona o caminho de execução. Isso é uma muleta porque, quando a biblioteca for atualizada, o wrapper terá que ser reescrito. Mas a alternativa — abandonar a biblioteca ou o suporte a dispositivos antigos — pode ser pior.

// Muleta para compatibilidade com API 29
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Dependências de terceiros com bugs

Uma biblioteca da qual o projeto depende tem um bug, mas atualizá-la pode levar semanas (PR necessário, revisão de código, publicação). Em vez de esperar, a equipe escreve um wrapper que corrige o comportamento da biblioteca em tempo real. Quando a versão corrigida da biblioteca for lançada, o wrapper é removido. Se não for removido, isso já é um problema arquitetônico.

Compreensão incompleta do sistema

Um novo desenvolvedor em um projeto legado não entende por que o código funciona dessa forma. Em vez de descobrir, ele adiciona uma nova condição sobre as existentes. Este é o tipo de muleta mais perigoso porque o autor não percebe que é uma muleta. O único remédio é a revisão de código e a programação em par para novos membros da equipe.

Quando uma muleta é justificada: abordagem pragmática

Nem toda muleta é má. No desenvolvimento real, a pureza absoluta do código é inatingível e frequentemente impraticável. Uma abordagem pragmática reconhece que soluções temporárias fazem parte do processo, mas exige consciência, documentação e um plano de remoção. Uma muleta é justificada quando resolve um problema de negócio mais rápido do que uma solução arquitetônica limpa.

Os critérios para uma muleta justificada: ela resolve um problema específico, tem um responsável (alguém encarregado de sua remoção) e existe um plano de refatoração. Se pelo menos uma dessas três condições estiver faltando, a muleta se transforma em dívida técnica. Ferramentas como comentários TODO com um ticket no rastreador são o método mínimo de documentação.

Exemplo de uma muleta justificada

Um bug crítico na branch de lançamento que precisa ser corrigido antes da implantação de amanhã. A solução limpa exige refatoração arquitetônica e levaria duas semanas. A muleta: adicionar uma verificação de nil e enviar a correção como hotfix. Condições de justificação: um ticket de refatoração foi criado no rastreador, um responsável foi designado e a muleta está marcada com um comentário. Duas semanas depois, a equipe retorna à tarefa.

// TODO: IT-1234 — remover esta muleta após refatoração do AuthService
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Como distinguir uma muleta temporária de um problema arquitetônico

A fronteira entre uma muleta consciente e um problema arquitetônico (dívida técnica) passa por dois parâmetros: consciência da decisão e existência de um plano para eliminá-la. Uma muleta é sempre uma solução temporária com vida útil conhecida. A dívida técnica é a consequência de muitas muletas deixadas sem atenção.

Quando uma muleta se torna um problema

A situação piora quando o número de muletas excede uma massa crítica. Cada nova muleta aumenta a “fragilidade” do sistema: uma mudança em um lugar quebra outro. Eventualmente, o desenvolvimento desacelera, os bugs se multiplicam e um novo desenvolvedor não consegue entender o código sem a ajuda do autor. Neste ponto, as muletas deixam de ser soluções temporárias e se tornam um problema arquitetônico.

Sinais de uma crise de muletas

Se o código contém cinco verificações aninhadas de versão do SO, fabricante do dispositivo e presença de uma biblioteca específica — isso não é uma muleta, é um problema arquitetônico. Se adicionar uma correção causa três regressões em módulos relacionados — as muletas não são mais locais. Se as revisões de código são rejeitadas regularmente por “mais uma muleta” — é hora de planejar a refatoração.

• A mesma muleta se repete em três ou mais lugares — hora de criar uma solução unificada
• Uma muleta vive mais de três sprints sem um plano de remoção — já é dívida técnica
• Um novo desenvolvedor não entende por que o código funciona assim — a muleta não está documentada
• Remover a muleta causa uma reação em cadeia de erros — a dependência da muleta se tornou arquitetônica

Refatoração de muletas: estratégia e prática

Refatorar muletas é o processo de substituir soluções temporárias por arquitetonicamente corretas. Isso leva tempo, portanto, é necessária uma estratégia de priorização: nem todas as muletas precisam ser eliminadas imediatamente. Uma boa estratégia é avaliar cada muleta por dois parâmetros: frequência de mudanças nessa área do código e impacto nos usuários.

Estratégia de priorização

Prioridade alta — muletas em módulos que mudam com frequência (lógica de negócios, UI de propósito geral) que retardam o desenvolvimento e causam regressões. Prioridade média — muletas em módulos raramente alterados, mas com impacto potencial nos usuários (processamento de pagamentos, autorização). Prioridade baixa — muletas em código legado que funciona de forma estável e não está planejado para modificação.

Processo de remoção passo a passo

Passo 1: inventário — encontre todos os TODOs e FIXMEs relacionados a muletas. Passo 2: avaliação — determine quais ainda são relevantes. Passo 3: planejamento — agende a refatoração de muletas em um sprint, começando pelas de alta prioridade. Passo 4: substituição — implemente a solução limpa, remova a muleta e seu comentário TODO. Passo 5: verificação — garanta que os testes passem e não haja regressões.

# Encontrar todas as muletas TODO no projeto
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Prevenção de novas muletas

A melhor maneira de combater muletas é não criá-las desnecessariamente. Antes de escrever uma muleta, faça a si mesmo três perguntas: posso implementar uma solução limpa em um tempo razoável? Existe uma alternativa que não seja uma muleta? A equipe terá tempo para voltar e reescrever isso? Se a resposta a pelo menos uma pergunta for “não” — pense novamente antes de “escorar” o código.