Pelo Fim Das Gambiarras

O problema que todo mundo ignora

Todo projeto de software tem uma fase em que as gambiarras começam a se acumular. Você começa com uma solução simples para um problema urgente, e ela vira dois meses depois outra solução para um problema que a primeira criou. O sistema funciona, mas só porque você sabe o caminho. O movimento pelo fim das gambiarras nasceu exatamente desse contexto. Não é sobre perfeccionismo. É sobre reconhecer que cada patch improvisado cobra um juros composto em complexidade, e que chegar num ponto onde ninguém mais consegue entrar no código sem medo é um sinal de fracasso do processo, não da equipe.

Definição prática: pelo fim das gambiarras

Em termos técnicos, o pelo fim das gambiarras defende a eliminação sistemática de soluções temporárias que se tornaram permanentes. Isso inclui funções com múltiplos parâmetros opcionais que só existem por compatibilidade reversa, blocos try-catch que engolem exceções sem log, variáveis globais usadas como atalho de comunicação entre módulos, e condições if/else aninhadas que existem porque "se funciona, não toca". O que não é: refatoração excessiva, arquitetura sobrematizada para problemas simples, ou eliminar código legado apenas por estética. Gambiarra é funcionalidade temporária que virou permanente. É diferente de código legado que ainda cumpre um propósito válido.

Começando: como identificar o que é gambiarra

A parte mais difícil nunca foi consertar. Foi reconhecer o problema. Eu passei meses achando que meu código estava "funcional mas feio", até entender que funcional mas feio em escala real significa inatingível. Use estes sinais concretos:

Métricas objetivas: funções com mais de 15 linhas de corpo antes do primeiro if/else. Classes com mais de 8 responsabilidades evidentes. Arquivos de configuração que têm 40% de comentários explicando por que determinadas decisões foram tomadas. Variáveis com nomes como temp_final_2 ou old_fix_backup. Comportamento observável: você faz uma alteração mínima e três coisas quebram em lugares não relacionados. Novos desenvolvedores levam mais de duas semanas para fazer sua primeira deploy sem gerar incidents. O histórico de commits tem mensagens como "hotfix", "workaround", "não perguntar", ou simplesmente ".".

Custo de manutenção: qualquer mudança no módulo leva mais de 3 dias para ser feita com segurança. O teste automatizado cobre 60% do código, mas os 40% restantes contêm 90% dos bugs em produção. Revisões de código viram sessões de arqueologia, não de engenharia.

Método de eliminação

Existe um processo concreto que eu uso, e que funciona consistentemente quando aplicado com disciplina. Não é bonitinho, mas é eficiente. Fase 1: Inventário (2-4 horas para sistemas pequenos, 1-2 dias para sistemas medianos)

Liste todos os workaround conhecidos. Cada um precisa ter: problema original que resolve, data de criação estimada, tamanho atual, e dependências. Use git blame para datas. Use complexidade ciclomática para tamanho. Não Julgue. Apenas registre. Fase 2: Categorização (1-2 horas)

Divida em três grupos. Gambyarras críticas: aquelas que causam falhas em produção regularmente. Gambiarras cosméticas: feias mas estáveis. Gambiarras históricas: não fazem mais sentido algum, mas ninguémremove por medo. Fase 3: Priorização baseada em ROI (1 hora)

Aqui está o insight que a maioria dos desenvolvedores perde: não comece pela gambiarra mais feia. Comece pela que gera mais custo de manutenção atual. Uma gambiarra que causa 2 incidentes por mês vale mais do que uma que é visualmente horrível mas nunca quebra. O cálculo é simples. Tempo médio de correção × frequência de ocorrência × impacto no negócio. O resultado dá uma prioridade numérica. Fature isso. Discuta com a equipe. Aplique.

Fase 4: Refatoração controlada (tempo variável) Cada gambiarra eliminada deve passar por três verificações antes de ser marcada como resolvida:

Testes existentes passam. Testes novos cobrem o caso de borda que a gambiarra escondia. A documentação do módulo foi atualizada para refletir o novo comportamento, não o antigo. Se alguma dessas falhar, a gambiarra voltou. Anote e reintegre ao inventário.

Um caso real que aprendi na prática

Em 2023, eu lidava com um sistema de notificações que tinha uma função chamada enviarNotificacao() com 47 parâmetros opcionais. A função existia desde 2019. Era o único ponto de contato entre o motor de eventos e os canais de entrega (email, SMS, push). O problema específico foi este: um update de biblioteca de SMS em fevereiro de 2024 quebrou 3 dos 47 parâmetros de forma silenciosa. A função continuava "funcionando" porque os parâmetros afetados nunca eram usados nos 90% dos casos normais. Mas quem enviava notificações de alta prioridadevia as mensagens chegarem sem o conteúdo correto.

A gambiarra raiz era simples: a função usava um array associativo onde chaves desconhecidas eram simplesmente ignoradas. Isso permitia que novos canais de notificação fossem adicionados sem mudar a assinatura, mas também permitia que parâmetros essências fossem perdidos em silencio. A solução que eu implementei levou 3 dias de trabalho. Eu criei um tipo valor para cada canal, com campos obrigatórios tipados. Cada canal tinha seu próprio validador. A função central passou a receber uma união discriminada, não um array. Os casos silenciosamente ignorados agora lançavam exceções explicitas no validation stage.

O resultado: em 6 meses, zero incidentes relacionados a notificações. O tempo médio para adicionar um novo canal caiu de 2 dias para 4 horas. E o sistema ficou mais simples, não mais complexo, apesar de mais código novo ter sido escrito.

Erros comuns que acontecem sempre

Eu já vi esse padrão se repetir em pelo menos oito projetos diferentes. Eliminar gambiarras sem adicionar testes. Isso é a receita para regressões. Cada gambiarra que sai do código precisa ter seu comportamento substituído por um teste que falha se o novo código se desviar. Sem isso, você está trocando um problema conhecido por um problema desconhecido.

Tratar toda gambiarra como igual. Algumas gambiarras custam R$ 200 em horas de desenvolvimento para remover. Outras custam R$ 2000. Trate todas com a mesma urgência e você vai gastar recursos onde não importa. Esquecer de comunicar a mudança. Quando você remove uma gambiarra que outra equipe consumia, mesmo que indiretamente, isso afeta elas. Se você não avisar, alguém vai descobrir quando quebrar em produção.

Quando o pelo fim das gambiarras não funciona

Seja honesto sobre as limitações. O movimento pelo fim das gambiarras não se aplica a todos os contextos. Sistemas legados com custo de modificação proibitivo: às vezes a gambiarra é a opção racional. Se migrar custa 6 meses de desenvolvimento e o sistema atual roda com 3 incidentes por ano, talvez seja melhor aceitar a gambiarra e planejar uma migração futura, não uma refatoração incremental.

Protótipos e MVPs: gambiarras são feature, não bug, nessa fase. O objetivo é validar hipótese, não construir base sustentável. Tentar aplicar refatoração sistemática em produto não validado é desperdício. Equipes sem maturidade em teste automatizado: o método depende fortemente de testes de regressão. Se você não tem cobertura básica, eliminate gambiarras manualmente é jogar dados ao vento. Nesse caso, o trabalho preliminar deve ser construir a rede de segurança, não destruir a estrutura existente.

Alternativas quando a refatoração não é viável

Se você não pode eliminar as gambiarras agora, pelo menos contenha o dano. Isola-as em módulos separados com interfaces claras. Documente explicitamente cada workaround com referência ao problema original. Estabeleça um orçamento de débito técnico: defina que X% do sprint será dedicado a reduzir gambiarras catalogadas. Isso transforma algo abstrato em algo mensurável e gerenciável. O resultado disso tudo não é um sistema perfeito. É um sistema onde o próximo desenvolvedor consegue entender o que cada linha faz, onde incidentes relacionados a code smell são raros, e onde o custo de manutenção não cresce exponencialmente com o tempo. Isso é o suficiente.