O problema que todo desenvolvedor brasileiro conhece na pele
Gambiarra é aquele código que funciona, mas ninguém entende por quê. É o patch que foi colado sobre outro patch há três anos, é a configuração que só funciona de quinta-feira porque alguém descobriu que o servidor X dá timeout às terças. A gente acumula gambiarras no projeto e no final vira um castelo de cartas que cai com um vento mais forte. O movimento pelo fim das gambiarras não surgiu como teoria. Surgiu da frustração prática de quem já teve que manter código que ninguém mais sabia como havia sido feito. O cerne é simples: todo workaround que não tem uma raiz documentada e tratada no código vira dívida técnica invisível. E dívida invisível cobra juros compostos.
pelo fim das gambiarras: o que realmente significa na prática
Não se trata de nunca mais fazer um workaround. Trabalhamos com sistemas reais, com APIs de terceiros que quebram sem aviso, com legado que não pode ser refeito do zero. O ponto é mais específico: todo patch que você aplica precisa ter um ticket rastreável, uma justificativa clara, e um prazo de remoção ou substituição. Se não tem isso, é gambiarra. E gambiarra sem data de validade é algo que vai morrer com quem sabe que existe. Achei útil começar com um exemplo real que me aconteceu ano passado. Estávamos integrando com um gateway de pagamento que tinha um bug conhecido: em certiandos horários de pico, a resposta vinha com campos JSON desordenados. O time queria usar uma regex para extrair o campo manualmente. Eu argumentei contra, não por princípio, mas porque aquele gateway já tinha atualizações de versão previstas para o mês seguinte e a regex ia quebrar de qualquer jeito.
Em vez disso, usei um middleware que normalizava o response com base no esquema oficial, mesmo quando os campos vinham embaralhados. A solução inicial levou duas horas a mais do que a regex, mas nos livrou de pelo menos três refatorações urgentes depois. Foi o tipo de decisão que ninguém elogia quando acontece, mas que te salva dormindo tranquilo quando o sistema entra em produção. O que falta em muita discussão sobre o tema é a nuance de que nem toda gambiarra é igual. Existe gambiarra de emergência, gambiarra de prazo, e gambiarra de preguiça. A primeira é válida desde que temporária. A segunda é inevitável em muitos contextos empresariais. A terceira é a que mais dói a longo prazo porque parece inofensiva quando é escrita.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Como implementar de verdade
O passo inicial é criar um ritual de code review que obrigue o autor a declarar explicitamente quando um trecho é um workaround. Coloque isso na template de pull request: "Este change contém algum workaround? Sim/Não. Justificativa:". Parece burocracia, mas foi exatamente essa pequena formalidade que fez minha equipe parar de esconder patches debaixo do tapete por padrão. O segundo passo é manter um arquivo chamado WORKAROUNDS.md na raiz do repositório. Não é documentação bonita. É uma lista crua de cada workaround existente, com link para o ticket de origem, data de aplicação, motivo, e a condição que faria ele ser removido. Quando alguém abre esse arquivo e vê que tem dez workarounds sem plano de remoção, a coisa muda de tom rapidamente.
O terceiro passo é o mais difícil: agendar a remoção. Tem workaround que fica ativo por dois anos e meio porque ninguém quer ser a pessoa que quebra algo que "só funciona assim". A solução que funcionou pra gente foi inserir nos sprints de manutenção obrigatória uma regra de que, a cada três workarounds no arquivo com mais de seis meses, um deles vira ticket de refatoração prioritário. Sem exceção. Uma armadilha comum é confundir gambiarra com flexibilidade. Código que lida com edge cases de forma elegante não é gambiarra. Gambiarra é quando você resolve um problema específico usando um artifício que depende de comportamento não documentado ou instável do sistema. A diferença é tênue na prática, mas faz toda diferença na hora de decidir se algo merece um cleanup ou se merece ficar.
Também é importante notar que essa abordagem tem limitações sérias. Em equipes pequenas ou em startups em velocidade extrema, o overhead de documentar cada workaround pode parecer proporcional ao benefício. Eu já vi times que adotaram o ritual e pararam de entregar features porque o processo de declaração travava o fluxo. Nesse caso, a recomendação é simples: comece apenas com workarounds que afetam integrações externas ou estabilidade de produção. Trabalhos internos de conveniência podem esperar. Outro ponto que raramente é mencionado: ferramentas automatizadas ajudam, mas não resolvem o problema sozinho. Análise estática consegue detectar código duplicado, má nomeação, e alguns padrões de workaround grosseiro. Nenhuma ferramenta consegue avaliar contexto empresarial suficiente pra decidir se um patch é gambiarra ou solução legítima. A decisão continua sendo humana. O processo é só um apoio pra garantir que a decisão seja consciente, não opcional.
Se você quer ver um caso concreto do que acontece quando isso é ignorado, olhe para qualquer sistema de saúde ou financeiro legado em operação no Brasil. A maior parte do que mantém essas coisas funcionando não tá em nenhum repositório. Tá na cabeça de alguém que vai se aposentar mês que vem. Isso não é hipérbole. É o resultado de décadas de patches não declarados sobre patches não declarados. Existem alternativas quando o trabalho de limpeza é muito grande. Migração incremental por strangler fig pattern, criação de uma camada de adaptação entre o legado e o novo código, e em alguns casos, simplesmente reescrever o módulo problemático do zero enquanto o antigo permanece rodando por baixo. Nenhuma dessas opções é barata ou rápida, mas todas são melhores do que deixar o caos acumular.
