Por que meu código quebrava nos testes mesmo "correto"
Passei uns seis meses na década de passado tentando entender por que certos problemas que pareciam resolvidos no papel simplesmente não funcionavam quando colocados em produção. A resposta, que eu demorei para aceitar, estava na lacuna entre o que os manuais dizem e o que a máquina realmente faz. O conceito de de acordo com a teoria aparece o tempo todo nesse contexto — em fóruns técnicos, em documentações, em reviews de código — como uma forma de marcar que algo é válido apenas no papel.
O que de acordo com a teoria significa na prática técnica
Ao de acordo com a teoria, um algoritmo ou procedimento funciona perfeitamente porque todas as condições são ideais. Na prática, as condições raramente são ideais. Isso vale para otimização de queries, para balanceamento de carga, para escolha de estruturas de dados. O que diferencia quem lê documentação de quem resolve problemas reais é justamente a capacidade de mapear onde a teoria falha e por quê. Um exemplo simples: a complexidade de tempo de um algoritmo de ordenação. A teoria diz que quicksort é O(n log n) em média. Eu já vi quicksort levar 40 segundos num array de 500 mil registros enquanto insertion sort, supostamente O(n²), completava em 0,3 segundo no mesmo cenário. A diferença estava nos dados. Eles já vinham parcialmente ordenados, e o quicksort ingênuo tem comportamento catastrófico exatamente nessa situação. O insertion sort, por outro lado, se beneficia de quase-ordem.
Como aplicar esse raciocínio no dia a dia
Quando você for escolher uma abordagem para um problema, o primeiro passo é listar explicitamente as premissas da teoria. Depois, pergunte se cada premissa se aplica ao seu caso. Se pelo menos uma delas for duvidosa, a solução teórica pode não funcionar, ou funcionar de forma inesperada. Na minha experiência, essa verificação costuma ser feita em três camadas:
1. Condições de contorno dos dados. Tamanho, formato, distribuição. Um cache de LRU funciona bem até os dados não caberem na memória. A partir daí, você vira um candidato a thrashing. Sem avisos. A teoria do cache hit rate começa a cair de forma não-linear quando a capacidade é ultrapassada, e poucos artigos mencionam isso claramente. 2. Condições de execução. Concursência, latência de rede, disponibilidade de recursos. Eu trabalhei num sistema de filas onde a lógica dizia que três workers processavam bem. Quando testamos com dez workers, o throughput caiu pela metade. O gargalo era locking em resources compartilhados, algo que a teoria de concorrência básica não destacava porque assumia recursos independentes.
3. Condições de contorno do ambiente. Versão do runtime, sistema operacional, hardware. Isso parece óbvio, mas é a falha mais frequente. Eu perdi duas semanas investigando um bug que só ocorria em containers Alpine porque a versão do glibc era incompatível com uma biblioteca C que eu importei. A teoria da portabilidade cross-platform não cobre isso, porque pressupõe que as bibliotecas nativas estão disponíveis.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um caso específico que aprendi da forma difícil
Tinha um serviço de sincronização de dados que usava checksums SHA-256 para detectar mudanças. A teoria dizia que colisões eram praticamente impossíveis. E eram. Mas o problema real era que dois arquivos com conteúdo completamente diferente geravam o mesmo hash quando hadamard-corrupted devido a um bug no driver de disco. O checksum passou a ser inválido sem que ninguém percebesse. A correção foi adicionar uma verificação de integridade em nível de bloco, não só no arquivo inteiro. Isso resolveu o problema, mas custou uns quatro dias de trabalho que eu poderia ter evitado prevendo a possibilidade. O que eu fiz depois disso foi criar um checklist mental antes de confiar em qualquer solução "teórica":
- Qual é a premissa principal que sustenta essa solução? - Onde essa premissa pode falhar no meu cenário?
- Tenho dados reais para validar, ou estou apenas acreditando na lógica? - Se der errado, qual é a fallback que já está implementada?
Limitações da abordagem teórica
A abordagem teórica tem desvantagens claras. Primeiro, ela pode criar uma falsa sensação de segurança. Segundo, quando você começa a questionar tudo, acaba paralisado. Terceiro, nem sempre há tempo para testes de validação antes de deploy. Minha recomendação prática é: use a teoria como ponto de partida, não como ponto final. Implemente um protótipo mínimo, coletem dados reais, e só então decida. Um benchmark de uma hora vale mais do que qualquer análise de complexidade assintótica. Eu costumo dizer para colegas juniores que passam a semana inteira estudando e nunca testam: vocês estão fazendo de acordo com a teoria, e a teoria não roda em produção.
A melhor analogia que eu já vi sobre isso veio de um colega que trabalha com infraestrutura: "teoria é o mapa. Produção é o terreno. O mapa pode estar errado, o terreno não." Ele tinha razão. Desde então, eu sempre valido no terreno antes de confiar no mapa.
