Aprender a usar o que está à mão
Na prática técnica, o quem não tem cão caça com gato é o nome que damos para aquela situação em que o recurso principal não está disponível e você precisa encontrar uma solução alternativa que funciona, ainda que não seja ideal. Isso acontece com frequência em desenvolvimento, infraestrutura e até em processos de design.
O que é quem não tem cão caça com gato na prática
Não é uma metodologia formal, mas sim um estado mental. Quando o servidor de produção cai, você não espera pela solução perfeita. Usa o banco local, improvisa uma API mockada, ou redistribui a carga manualmente. O princípio é simples: o objetivo continua sendo o mesmo, só muda o conjunto de ferramentas. Na minha experiência, encontrei esse cenário recentemente durante uma migração de banco de dados. O motor principal que estávamos usando tinha uma limitação inesperada com queries recursivas profundas. Em vez de refazer toda a arquitetura, fiz uma camada de tradução entre o ORM e o banco substituto, mapeando manualmente os joins que a função nativa fazia sozinha. Complicou? Sim. Funcionou? Também.
Como aplicar esse raciocínio de forma estruturada
A primeira coisa é identificar o que está realmente bloqueando. Muitas vezes o que parece um problema insolvível é apenas uma variável mal isolada. No caso da migração que mencionei, o gargalo era uma única procedure armazenada que eu poderia ter substituído por uma view materializada se tivesse previsto isso antes. Para chegar a essa conclusão, fiz o seguinte: mapeei todas as dependências da função problemática, calculei o tempo de execução atual versus o tempo estimado com uma solução alternativa, e documentei os pontos de falha aceitáveis. Isso reduziu o período de adaptação de cerca de três semanas para aproximadamente quatro dias.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Erros comuns que eu vejo todos os dias
O erro mais frequente é tratar a solução alternativa como permanente. A workarounds funcionam porque resolveram um problema imediato, mas acabam virando padrão. Isso gera débito técnico silencioso que só aparece quando a escala aumenta. Eu vi isso acontecer em pelo menos três projetos diferentes. Outro problema comum é não documentar o que foi improvisado. Quando o recurso original retorna, ninguém sabe o que precisa ser refatorado. Criei o hábito de manter um arquivo chamado WORKAROUNDS.md em cada projeto que entra nesse estado, registrando data, motivo, solução aplicada e ticket futuro para correção.
Limitações reais desse tipo de abordagem
Não funciona para tudo. Quando a inconsistência de dados é crítica — como em sistemas financeiros ou médicos — a solução alternativa precisa passar pelos mesmos testes de integridade que a original. Improvisar sem validação nesses contextos é simplesmente pedir problemas. Se a tolerância a erro é zero, o caminho certo é adiar a entrega ou solicitar os recursos adequados, não tentar contornar o problema. Além disso, soluções alternativas consomem mais tempo de manutenção a longo prazo. Cada patch adicionado ao código para compensar a ausência do recurso principal precisa ser revisado, testado e eventualmente removido. Isso dobra o esforço de manutenção em comparação com uma implementação direta.
Alternativas quando o "gato" não basta
Às vezes o melhor é não improvisar. Se o recurso principal está fora do orçamento ou do prazo, considere três opções antes de partir para a solução de contorno: terceirizar o componente problemático, reduzir o escopo para remover a dependência, ou estender o prazo com a parte interessada. Eu prefiro sempre. Muitas vezes uma delas é viável e evita meses de trabalho com patches. O que diferencia um profissional experiente de um iniciante nessa situação não é saber o nome do recurso que falta, mas conseguir avaliar rapidamente se vale a pena esperar, adaptar ou desistir do escopo original. Essa avaliação leva tempo de observação e fracassos anteriores para calibrar.
