Gambiarra na programação: o que é, quais existem e como funciona

O que é uma gambiarra na programação?

Gambiarra — é um termo informal para uma solução de software que é funcionalmente correta, mas tecnicamente subótima. Esse código funciona, passa nos testes e até chega à produção, mas lê-lo dá vontade de reescrever tudo do zero. No ambiente anglófono, são usados os termos workaround, kludge (kluge), hack ou quick-and-dirty fix.

O termo vem de uma metáfora doméstica: se a perna de uma cadeira quebra, você pode prendê-la com fita adesiva — a cadeira funciona novamente, mas a solução é temporária e feia. O mesmo acontece na programação: um bug é corrigido com hardcode, uma gambiarra com timeout ou uma solução alternativa através de uma API não documentada. O código compila, a aplicação não cai, mas a solução não pode ser chamada de qualidade.

Uma diferença importante: bug — é quando o código não funciona. Gambiarra — é quando o código funciona, mas está mal projetado. Uma gambiarra é sempre uma escolha consciente do desenvolvedor: “Eu sei que isso é feio, mas agora resolve o problema.”

Segundo a Stripe (2024), os desenvolvedores gastam em média 17 horas por semana lidando com dívida técnica e gambiarras — quase metade do seu tempo de trabalho. Isso é uma perda direta de produtividade da equipe.

Quando e por que surgem as gambiarras

A primeira e principal causa são os prazos. Quando falta um dia para o lançamento e um bug crítico ainda não foi corrigido, a equipe escolhe uma solução rápida em vez da correta. Hardcodar um valor, desabilitar uma verificação, adicionar sleep() — exemplos clássicos de gambiarras de prazo. Um desenvolvedor experiente sempre marca esses lugares com TODO ou FIXME.

A segunda causa é a incompatibilidade de API. Uma biblioteca ou framework de terceiros se comporta de forma diferente da documentada. O framework não exporta a classe necessária, um método está marcado como obsoleto e não há alternativa. O desenvolvedor é forçado a usar reflexão, API interna ou uma solução alternativa. Em Java, isso pode ser acesso via setAccessible(true); em Swift — @objc e performSelector.

A terceira causa é o código legado. Um desenvolvedor herda um projeto escrito há 5-10 anos em uma versão desatualizada do framework. Não há tempo ou orçamento para reescrever todo o módulo, então a nova funcionalidade é “colada” ao código antigo através de gambiarras. Gradualmente, tantas camadas se acumulam que o módulo se transforma em uma “grande bola de lama” (big ball of mud).

A quarta causa é a falta de testes. A refatoração sem testes é perigosa: alterar a arquitetura pode quebrar a funcionalidade existente. Quando não há testes, o desenvolvedor prefere adicionar uma gambiarra sobre o código funcional do que arriscar a estabilidade. Segundo o Google Testing Blog (2024), equipes sem testes usam soluções de gambiarra 3 vezes mais.

Tipos de gambiarras

A classificação das gambiarras ajuda a equipe a entender que tipo de dívida técnica está enfrentando e a escolher a estratégia de eliminação correta. Vamos ver os principais tipos.

Hardcode — o tipo mais comum. Em vez de configuração, recurso ou parâmetro, um valor fixo é usado no código. Exemplo: URL de servidor hardcodada, timeout de 5 segundos, tamanho de fonte 16pt. O hardcode torna o código não escalável e requer recompilação para qualquer alteração.

Copiar e colar — duplicar um trecho de código com pequenas alterações em vez de extrair a lógica comum. Sintoma clássico: há 3 métodos semelhantes no projeto que diferem em uma linha. Copiar e colar acelera a escrita do código no momento da tarefa, mas retarda a manutenção em 10 vezes no futuro — a correção precisa ser aplicada em 3 lugares em vez de um.

Try-catch vazio — um bloco catch que não faz nada ou apenas registra o erro sem tratá-lo. Essa gambiarra “silencia” a exceção, mas não resolve sua causa. A aplicação continua funcionando, mas os dados podem ser corrompidos e o usuário pode não receber feedback.

Sleep no código — Thread.sleep(500) ou DispatchQueue.main.asyncAfter para esperar quando deveria haver um evento ou callback. Esse código não é confiável: em um dispositivo lento, 500 ms podem não ser suficientes; em um rápido, a pausa será desnecessária. Use CountDownLatch, Semaphore ou async/await com temporização adequada.

Bandeiras de compatibilidade — cascatas if-else que verificam a versão do SO, modelo do dispositivo ou disponibilidade de recurso. Quando há mais de 3-4 bandeiras, o código vira espaguete. A solução é o padrão Strategy ou Feature Flags através de configuração.

Gambiarra vs dívida técnica

Muitos desenvolvedores confundem gambiarra e dívida técnica. A diferença está na escala e consciência. Gambiarra — é uma solução local e específica (um método, uma classe). Dívida técnica — é um problema sistêmico que afeta a arquitetura de um módulo ou de toda a aplicação.

A metáfora de Ward Cunningham (criador do termo Dívida Técnica): dívida técnica é como pegar um empréstimo bancário. Você pega dinheiro agora para construir a casa mais rápido, mas depois paga juros. Gambiarra — é como pregar um prego com martelo em vez de uma pistola de pregos: o trabalho é feito, mas de forma menos eficiente.

Uma gambiarra não cria dívida técnica. Mas 50 gambiarras em um módulo = dívida arquitetural. Portanto, regra da equipe: cada gambiarra é registrada no code review ou no task tracker, e a equipe revisa regularmente (uma vez por sprint) as soluções de gambiarra acumuladas.

Segundo o Spotify Engineering (2023), equipes que rastreiam gambiarras no código (através de uma etiqueta TODO especial ou anotação personalizada) reduzem o tempo de refatoração em 30% — porque não perdem horas procurando lugares problemáticos.

Como se livrar das gambiarras

O primeiro passo é o inventário. Pesquise na base de código palavras-chave: TODO, FIXME, HACK, WORKAROUND, KLUDGE. IDEs modernas as destacam com uma cor separada. O GitHub também exibe TODO na interface do Pull Request. Faça uma lista de todas as gambiarras com prioridade.

O segundo passo é a priorização. Nem todas as gambiarras precisam ser corrigidas imediatamente. Prioridade = frequência de alterações no arquivo × criticidade. Se um arquivo muda 2 vezes por ano, a gambiarra pode esperar. Se um módulo é tocado em todo sprint — a gambiarra deve ser corrigida primeiro.

O terceiro passo é a refatoração com testes. Nunca refatore uma gambiarra sem testes. Primeiro escreva um teste que verifique o comportamento atual (com a gambiarra), depois refatore, depois certifique-se de que o teste passe. Sem isso, a refatoração de uma gambiarra pode quebrar a funcionalidade para a qual foi escrita.

// Before: URL hardcodada workaround
fun getApiUrl(): String {
    return "https://api.example.com/v2"
}

// After: configuração via BuildConfig
fun getApiUrl(): String {
    return BuildConfig.API_BASE_URL
}

O quarto passo é a automação. Configure um linter que proíba certos padrões de gambiarra. Por exemplo, Detekt para Kotlin pode verificar a ausência de Thread.sleep() em código de produção, ESLint pode proibir console.log no projeto. Isso impede o surgimento de novas gambiarras do mesmo tipo.

Quando uma gambiarra é justificada

Apesar da conotação negativa do termo, uma gambiarra pode ser uma solução justificada. A condição principal: a gambiarra é temporária, explicitamente marcada e tem um plano de substituição. No código de produção de todo grande projeto, existem centenas de gambiarras justificadas.

Situação 1: hotfix em produção. Um bug crítico afeta todos os usuários. A equipe precisa de uma correção em uma hora. A abordagem correta: corrija o bug de qualquer maneira, implante o hotfix. Depois, no dia seguinte, escreva a solução adequada e feche o ticket. Um hotfix é uma gambiarra justificada se não durar mais de 48 horas.

Situação 2: esperar uma nova versão da biblioteca. Um framework contém um bug corrigido no master, mas o lançamento será em 2 semanas. Em vez de escrever código alternativo complexo, a equipe adiciona uma gambiarra com a nota “REMOVE after library 3.2.” Quando a versão 3.2 é lançada, a gambiarra é removida.

Situação 3: fechamento de startup ou MVP. No estágio de MVP, a velocidade é mais importante que a arquitetura. Gambiarras no início são normais. O problema surge quando a startup não se transforma em produto, mas as gambiarras permanecem. Recomendação: após uma rodada de financiamento, aloque um sprint para pagar a dívida técnica crítica.

O princípio principal: “Código legado é código sem testes” (Michael Feathers). Se uma gambiarra está coberta por um teste e explicitamente documentada — é gerenciável. Se está pendurada sem comentários por 2 anos em um módulo esquecido — não é mais uma gambiarra, mas um problema arquitetural.