De Acordo Com O Código

Como seguir a lógica do sistema sem perder a cabeça

A minha primeira vez com de acordo com o código aconteceu num serviço de produção que eu não podia parar no meio da noite. O deploy havia falhado e ninguém sabia se era problema na configuração ou se o framework tinha sido atualizado por alguém sem avisar. A decisão foi simples: de acordo com o código mesmo, não com o que estava nos slides do Jira. Eu abri o repositório, fui direto para o commit mais recente, e percebi que uma variável de ambiente tinha sido sobrescrita em três lugares diferentes com nomes parecidos. O erro que o log mostrava era uma mensagem genérica que qualquer desenvolvedor iniciante ignoraria. A solução? Mapear todas as variáveis, cruzar com o Dockerfile, e achar o conflito. Levei vinte minutos. Sem essa abordagem, levaria horas. Seguir de acordo com o código é usar o que está escrito no sistema como fonte primária, não o que está em documentação, nem o que alguém lembra ter ouvido. Isso inclui commits, logs de execução, variáveis de ambiente, schema de banco, e arquivos de configuração. Quando há contradição entre o que está documentado e o que o código mostra, o código sempre ganha, independente de quem escreveu a doc. Eu tenho seen documentação com dois anos de defasagem que ainda está linkada no README. Ninguém corrige porque ninguém quer passar o trabalho todo de novo. O problema é que muita gente confunde de acordo com o código com ler o código cegamente. Não é a mesma coisa. Ler o código sem contexto é o que te leva a achar que um bug é no frontend quando o erro está na API. A diferença é sutil mas faz um Ab de diferença no tempo de resolução. Você lê o código, mas cruza com o comportamento em tempo de execução, com os logs, e com a linha do tempo dos commits. É isso que separa quem resolve rápido de quem fica dias girando.

Por onde começar quando você não tem certeza de nada

A primeira coisa é identificar o que o sistema realmente faz versus o que ele deveria fazer. Para isso você precisa rodar o programa e observar. Não adianta só ler. Há um erro comum aqui: muitos desenvolvedores confunden leitura com debug. Ler é passivo. Debug é interativo. Se você quer aplicar de acordo com o código, precisa estar disposto a rodar comandos, inspecionar estado, e seguir o fluxo até encontrar o ponto de ruptura. No meu caso, eu costumo começar com três comandos. Primeiro, verificar o git log para entender a linha do tempo das mudanças. Segundo, rodar o sistema em modo debug se houver. Terceiro, inspecionar as variáveis de ambiente que estão ativas. Esses três passos já eliminam setenta por cento dos problemas que aparecem em threads de suporte. O resto é detalhe.

O meu maior erro e o que eu aprendi

Eu já caí numa armadilha clássica por confiar demais no que eu achava que era óbvio. Era um sistema de pagamentos que falhava apenas em produção. Em homologação funcionava perfeitamente. Eu gastei duas semanas tentando reproduzir o bug localmente até aceitar que o problema só existia no ambiente real. O que eu não tinha feito antes era comparar o código de production com o de homologação commit por commit. Quando finalmente fiz isso, encontrei uma flag que estava desligada em um dos ambientes e ligada no outro. Nada no log indicava isso. A flag simplesmente alterava o comportamento de uma libraria externa que eu nem sabia que estava sendo usada. Depois disso, eu nunca maisConfio em que dois ambientes sejam idênticos só porque o código-fonte é o mesmo. O workaround que eu desenvolvi foi criar um script que gera um diff automático entre os ambientes, incluindo variáveis, versões de dependências, e flags de runtime. Esse script agora é parte do meu checklist obrigatório antes de qualquer investigação. Eu levo talvez cinco minutos para rodar, e economizo horas de busca.

Pegadinhas que quase ninguém menciona

Existe um limite para de acordo com o código que as pessoas não costumam discutir. Quando o código é legado, mal escrito, ou escrito por três pessoas diferentes em três anos distintos, seguir o código pode te levar a decisões erradas. Eu já vi times inteiros optarem por manter um comportamento bugado porque o código justificava o bug. Numa situação dessas, o código não é fonte, é armadilha. O conselho pragmático é: use o código como referência, mas valide com dados reais de uso. Se o código diz X mas os usuários reportam Y, Y é que importa. Outro ponto cego é a relação entre código e terceirização. Muitas vezes o comportamento que você vê não está no seu repositório. Está num pacote npm, numa lib Java, num serviço de microbackend que ninguém mais domina. Nesse caso, de acordo com o código significa ir até o código da dependência, não apenas o seu. Eu já perdi uma tarde inteira seguindo um import que levava a uma sub-dependência transitiva. O bug estava lá embaixo, em código que eu não mantinha e nem via como meu responsabilidade até aquele momento.

Quando abandonar a abordagem

Nem sempre faz sentido ir de acordo com o código. Se o problema é de infraestrutura, de rede, ou de provisão de recursos, o código pode ser irrelevante. Eu já perdi tempo investigando um erro de timeout como se fosse bug de lógica, quando na verdade era o balanceador de carga cortando conexões antes do deadline. O código estava perfeito. A infraestrutura é que estava estragada. Saber quando mudar de rota também é parte da experiência. O sinal de alerta é quando você já rodou o código três vezes, já inspecionou o estado, e ainda não encontra o problema. Nesse ponto, expandir o escopo para fora do código costuma ser a jogada certa.