Pelo Fim Das Gambiarras

O problema das gambiarras que ninguém quer admitir

Eu passei os últimos anos trabalhando com sistemas legados e equipes que acumularam camadas de solução temporária até o ponto em que nenhuma mudança era mais possível sem quebrar outra coisa. Isso não é um problema teoricamente interessante. É um problema que custa horas de debugging às 3 da manhã e causa chamados no fim de semana. Gambiarras surgem por motivos reais. Prazos apertados, documentação inexistente, pessoas que saem do projeto antes de documentar, requisitos que mudam três vezes. Ninguém acorda de manhã e decide ser preguiçoso. A gambiarra entra porque o caminho correto levaria uma semana e o sistema precisa funcionar hoje. O problema é que essas soluções temporárias raramente são substituídas. Elas viram infraestrutura.

pelo fim das gambiarras: o que isso significa na prática

A ideia não é ingenuidade. Não se trata de julgar desenvolvedores que precisam entregar algo rápido. Significa ter um processo estruturado para identificar cada solução temporária que entra no código, rastreá-la, e definir um plano concreto para substituição. Sem esse processo, a gambiarra permanece para sempre como parte do sistema. Eu já vi loops com três try-catch aninhados tratando um erro de formatação de data que existia desde 2017. Esse tipo de coisa não desaparece sozinha. No meu caso, eu precisei lidar com um sistema onde um campo numérico de valor monetário era armazenado como string por conta de uma migracao precipitada entre duas versões de banco de dados. A conversão acontecia em cada consulta, com tratamento de erros customizado que mascara vazamentos reais de dados. Eu identifiquei esse problema mapeando todas as consultas que continham CAST ou TRY_CAST manual. A solução foi criar uma view materializada no banco que normaliza os dados, ajustar o mapeamento ORM, e só então remover as conversões de aplicação. Levei cerca de três semanas, mas eliminou uma classe inteira de bugs que acontecia uma vez por mês.

Como identificar gambiarras no seu código

O primeiro passo é entender onde procurar. Gambiarras raramente aparecem como comentários óbvios. Elas se disfarçam de código produtivo. Os sinais mais comuns incluem: condições if que tratam casos especiais sem uma explicação clara no comentário, retries infinitos ou com contadores fixos hardcoded, strings mágicas que aparecem repetidas vezes sem definição centralizada, e handlers de exceção genéricos que consomem o erro sem fazer nada útil. A técnica mais eficiente que eu uso é revisar o histórico de commits com filtro por palavras-chave. Termos como "temp", "workaround", "fix rapido", "provisório", "hack", "gambiarra" aparecendo em mensagens de commit são indicadores quase infalíveis. Quando encontrei esses termos em um repositório interno, mapeei 47 commits que continham essa linguagem ao longo de dois anos. A maioria dos desenvolvedores nem sabia que aquelas alterações existiam no código atual. Outra abordagem prática é rodar um search por padrões. Em projetos Python, eu costumo procurar por except sem variável de exceção, pass statements em blocos de código, e time.sleep com valores fixos. Em Java, System.out.println em código de produção, catch Exception, e strings numéricas sem constante. Em SQL, SELECT * combinado com WHERE que usa funções em colunas indexadas. Cada linguagem tem seus sintomas próprios.

O processo de substituição passo a passo

Substituir uma gambiarra exige mais do que reescrever o trecho problemático. Você precisa garantir que a solução temporária estava realmente cobrindo algum problema real, e não apenas escondendo um comportamento inconsistente que, se removido bruscamente, faria o sistema falhar de forma silenciosa. Passo um: documente a gambiarra exatamente como ela funciona agora, incluindo todos os casos extremos que você conseguir reproduzir. Eu mantenho um arquivo markdown simples por cada gambiarra identificada, com link para o trecho de código, data de criação (quando consigo descobrir), e lista de cenários de teste que passam graças à gambiarra. Isso se torna sua base de evidências. Passo dois: escreva testes que cubram o comportamento atual antes de qualquer alteração. Se não houver testes existentes, esse é o momento crítico. Eu já perdi horas em projetos porque a gambiarra estava funcionando como um patch não declarado para um edge case que ninguém havia escrito como teste. Sem cobertura, você não tem como saber se a substituição quebrou algo que a gambiarra protegeu.

Passo três: planeje a substituição em isolamento. Não faça diretamente no main branch. Crie uma branch específica, implemente a solução limpa, e rode todos os testes. A solução limpa geralmente é mais simples do que parece porque a gambiaria existe para contornar restrições que já foram resolvidas em outra parte do sistema ou que simplesmente deixaram de ser relevantes. Passo quatro: implemente com parâmetro de feature toggle quando possível. Isso permite que a nova solução coexista com a antiga durante algum tempo, facilitando rollback em caso de problema. Em projetos menores, pelo menos use deployment gradativo com monitoreamento ativo nas primeiras 48 horas após a troca. Passo cinco: remova a gambiaria e documente a mudança. O registro de why importa mais do que o que mudou. Outros desenvolvedores precisam entender por que aquela solução foi substituída, não apenas como funciona o novo código.

Pitfalls comuns que pioram a situação

O erro mais frequente é substituir uma gambiaria por outra gambiaria com aparência melhor. Um exemplo clássico: trocar um try-catch que esconde o erro por um decorator elegante que logs o erro e continua processamento normalmente. O problema subjacente continua lá, apenas com mais camadas de abstração. A gambiaria original era visivelmente ruim. A nova versão parece profissional e passa despercebida por muito mais tempo. Outro problema é tentar resolver todas as gambiarias de uma vez. Isso cria projetos de refatoração massiva que nunca saem do papel ou que introduzem bugs em cascata. Eu prefiro a abordagem incremental. Identifico as gambiarias por ordem de impacto: primeiro as que causam falhas reais, depois as que geram lentidão, depois as que apenas poluem o código. Cada ciclo de substituição dura no máximo duas semanas. Depois disso, reviso os resultados e escolho o próximo alvo. Também existe o risco de assumir que gambiarias antigas ainda são necessárias. Às vezes a limitação que justificou a solução temporária já foi eliminada por outra atualização do sistema, mas o patch permanece por inércia. Eu recomendo verificar a linha do tempo do projeto antes de substituir. Se a razão original da gambiaria foi resolvida em uma release anterior, a substituição tende a ser mais simples e rápida do que o esperado.

Quando gambiarras são a escolha certa

É importante reconhecer que nem tudo que parece uma gambiaria merece remoção. Há situações em que uma solução temporária é tecnicamente superior à alternativa correta por motivos práticos. Manutenção de interoperabilidade com sistemas legados que não podem ser modificados, integrações com APIs de terceiros instáveis, e protótipos de validação de negócio são exemplos válidos. A diferença entre uma gambiaria aceitável e uma problemática é a transparência. Soluções que estão documentadas, com prazo de vida definido e plano de substituição, são ferramentas. Soluções que existem sem registro e sem prazo de expiração são passivo técnico. Eu costumo pedir que qualquer alteração que se qualifique como gambiaria tenha um issue aberto no tracker com o rótulo tech-debt e uma data estimada de resolução. Sem isso, a gambiaria entra no sistema como componente permanente. A abordagem pelo fim das gambiarras não elimina a necessidade de soluções pragmáticas. Ela transforma o caos acumulativo em dívidas visíveis e gerenciáveis. Isso é tudo que faz sentido.