Gambiarra em programação: quando ela salva e quando vira dívida

Gambiarra é sempre ruim? Não. Na programação, gambiarra é a solução improvisada que resolve o problema agora sem resolver do jeito certo: um try/except que engole o erro, um setTimeout de dois segundos “para dar tempo do dado chegar”, um valor fixo no código porque a configuração ainda não existe. Às vezes ela é exatamente o que a situação pede. O problema começa quando ninguém volta para desfazê-la.

Em inglês o pessoal fala em workaround, hack ou quick fix. O conceito técnico mais próximo é dívida técnica, que Martin Fowler explica no texto Technical Debt, de Martin Fowler: o atalho economiza tempo hoje, mas cobra “juros” em forma de esforço extra toda vez que alguém precisa mexer naquele trecho. A gambiarra é a dívida contraída; a dor de manutenção são os juros.

Como verbete do glossário de programação, este texto parte dos erros que fazem um improviso inocente virar problema permanente. Cada um tem um custo, e quase todos são evitáveis com hábitos baratos.

Gambiarra sem registro é dívida que ninguém sabe que existe

O erro mais caro não é fazer a gambiarra. É fazê-la em silêncio.

Seis meses depois, outra pessoa (ou você mesmo, sem lembrar de nada) encontra um if (cliente.id === 4821) return; no meio do faturamento. Ninguém sabe por que está ali, então ninguém tem coragem de tirar. O custo é tempo de investigação multiplicado por cada pessoa que passar por ali.

O remédio custa dois minutos:

// GAMBIARRA: cliente 4821 tem contrato antigo sem CNPJ cadastrado.
// Remover quando o cadastro for corrigido (issue #312).
if (cliente.id === 4821) return;

Comentário com o motivo, um link para a tarefa e um critério de saída. Muitos times padronizam marcadores como TODO, FIXME ou HACK justamente para que uma busca no projeto liste todas as pendências de uma vez.

Tratar o “provisório” como se ele fosse sair sozinho

Existe uma piada antiga no meio: nada é mais permanente do que uma solução temporária. Ela é engraçada porque é verdade. A gambiarra entra em produção, o sistema funciona, a próxima tarefa chega e a correção definitiva nunca vira prioridade.

O custo aqui é acumulativo. Uma gambiarra sozinha incomoda pouco; vinte delas transformam qualquer mudança simples em uma caça ao tesouro. Para não cair nisso:

• Abra a tarefa da correção definitiva no mesmo dia em que fizer o improviso.
• Coloque prazo ou gatilho: “antes da próxima release” ou “quando entrar o segundo cliente com esse caso”.
• Reserve uma fatia fixa de cada ciclo (alguns times usam 10% a 20% do tempo da sprint) para pagar esse tipo de dívida.

Engolir o erro para a tela parar de quebrar

Esta é a gambiarra mais traiçoeira, porque ela esconde o sintoma e mantém a doença:

try:
    salvar_pedido(pedido)
except Exception:
    pass  # às vezes dá erro, mas segue

O usuário não vê mais a mensagem de erro. Também não vê o pedido salvo. E você não fica sabendo de nada, porque nenhum log foi gerado. O custo aparece semanas depois, quando o financeiro pergunta por que 3% dos pedidos sumiram.

Se precisar mesmo capturar a exceção para manter o sistema de pé, pelo menos registre: logger.exception("falha ao salvar pedido %s", pedido.id). Gambiarra que deixa rastro pode ser investigada. Gambiarra muda, não.

Remendar no lugar errado da cadeia

A API devolve a data no formato errado. Em vez de corrigir na API, alguém converte no front-end. Depois o app mobile precisa da mesma data e ganha a sua própria conversão. Depois o relatório em PDF. Agora são três remendos, cada um um pouco diferente, para um único problema de origem.

O custo é a inconsistência: cada tela mostra a data de um jeito, e corrigir a origem passa a quebrar os três remendos ao mesmo tempo. A pergunta que evita isso é simples: onde esse problema nasce? Às vezes não dá para corrigir na origem (é uma API de terceiro, por exemplo). Aí vale criar um único adaptador e fazer todo mundo passar por ele, em vez de espalhar conversões.

Confundir gambiarra consciente com gambiarra por desconhecimento

Fowler propõe um quadrante útil, o quadrante da dívida técnica, que separa a dívida deliberada da inadvertida e a prudente da imprudente. Traduzindo para o dia a dia:

O quadrante de cima à esquerda é a gambiarra que salva: decisão tomada com os olhos abertos, com prazo de retorno. O de baixo à direita é o que mais aparece em código de iniciante, e a saída não é culpa, é estudo. Se você colou um trecho que funciona sem entender, volte nele depois e descubra o que cada linha faz.

Como reconhecer uma gambiarra no código de outra pessoa

Alguns sinais aparecem com frequência em projetos brasileiros, do sistema de ERP da empresa pequena ao app de startup:

• IDs ou e-mails específicos escritos direto em condições (if user.email == "[email protected]").
• sleep ou setTimeout com números arbitrários para “esperar” algo assíncrono.
• Arquivos com nomes como servico_novo_v2_final.js convivendo com servico.js.
• Blocos inteiros comentados “para caso precise voltar”, em vez de confiar no histórico do Git.

Encontrar um desses não é motivo para sair reescrevendo tudo. Primeiro pergunte ao time ou consulte o histórico com git blame e git log: muitas vezes o commit original explica o motivo e você descobre que a correção definitiva é mais simples do que parecia.

Achar que a gambiarra só afeta quem escreveu

Ela afeta o colega que vai dar manutenção, o cliente que vai topar com o caso de borda e o próximo dev contratado, que vai levar mais tempo para entender o sistema. Em equipe, uma gambiarra sem combinação é uma decisão individual com custo coletivo.

Por isso, em times organizados, o improviso passa pelo code review como qualquer outra mudança. O revisor não precisa barrar; ele precisa saber que aquilo é provisório e concordar com o plano de saída.

Quando a gambiarra é a escolha certa

Há momentos em que improvisar é a decisão profissional:

1. Produção caiu e clientes estão sem acesso. Primeiro estanca, depois corrige direito.
2. Validação de ideia. Se você nem sabe se alguém vai usar a funcionalidade, não faz sentido construir a versão definitiva. O texto sobre validar uma startup antes de desenvolver o produto completo mostra bem essa lógica.
3. Dependência externa quebrada. A biblioteca tem um bug conhecido e a correção oficial ainda não saiu. Um contorno documentado, com link para a issue do projeto, é perfeitamente aceitável.

Nos três casos, o que separa a gambiarra boa da ruim é o mesmo: ela tem motivo escrito, dono e data para sair.

O hábito que impede o improviso de virar arquitetura

A partir de hoje, evite um único erro: fazer gambiarra sem deixar o bilhete. Antes de dar commit em qualquer solução provisória, escreva o comentário com o motivo, abra a tarefa da correção e coloque o número dela no código. São três minutos. É o que transforma “código misterioso que ninguém toca” em “pendência conhecida com plano de saída”, e é isso que o seu colega (e você daqui a seis meses) vai agradecer.