Quando o sistema funciona mas você não consegue explicar por quê
Você entra num projeto legado, rodando em produção há sete anos, e descobre que o código fonte principal é simplesmente um arquivo de 40 mil linhas sem comentários, sem testes, sem documentação. O cliente liga dizendo que o sistema caiu e você precisa resolver. Você vê o stack trace e percebe que ninguém mais no time sabe o que acontece ali. É o famoso nao sei so sei que foi assim em estado puro. Eu passei dois anos inteiros lidando com isso na indústria. A verdade é que a maioria das empresas que eu trabalhei tinha pelo menos um módulo crítico mantido vivo por esse princípio. Não é falha de alguém. É uma consequência natural de prazos apertados, rotatividade alta e falta de cultura de documentação. O problema é que quando isso vira padrão e não exceção, você acaba gastando mais tempo tentando recriar no paper o que alguém já fez de forma empírica do que resolvendo o problema de fato.
O verdadeiro significado de nao sei so sei que foi assim
Muita gente acha que essa expressão descreve incompetência. Na prática, ela descreve conhecimento tácito. Polanyi escreveu sobre isso nos anos 1960. Você sabe mais do que consegue falar. Um engenheiro sênior que depura um erro de race condition ouvindo o sistema pode ter acumulado esse conhecimento em três anos de prática, mas não consegue explicar o raciocínio passo a passo para um junior. A diferença é que esse conhecimento não está armazenado em lugar nenhum. Se essa pessoa sair da empresa amanhã, o saber sai junto. O que acontece na prática é que alguém faz algo funcionar, mesmo sem entender completamente o porquê, e depois ninguém mais se sente à vontade para questionar ou documentar porque parece óbvio que funcionou. Funciona em produção. Por que tocar? Essa mentalidade mata projetos silenciosamente. Eu vi times inteiros abandonarem refatoração porque o risco de quebrar algo que funciona de forma misteriosa era maior do que o benefício esperado de entendimento.
Como lidar com isso na prática
A primeira coisa que você precisa fazer quando se depara com um sistema que segue o princípio do nao sei so sei que foi assim é parar de tentar entender tudo de uma vez. Eu tentei ler o código inteiro no primeiro dia de um projeto legado e perdi duas semanas. O correto é começar pelo comportamento externo. Anote todas as entradas do sistema, todas as saídas esperadas, e todas as formas como ele falha. Depois você mapeia o fluxo crítico e trabalha de fora para dentro. O método que funcionou para mim foi criar um mapa de dependências baseado em logs de produção. Em vez de ler código, eu rastreei requisições reais de produção por três dias consecutivos. Anotei cada endpoint, cada chamada de banco, cada serviço externo. O resultado foi um documento de sessenta páginas que mostrou exatamente onde estavam os pontos críticos. Esse trabalho geralmente leva entre três e cinco dias de coleta mais dois dias de análise. Nada comparado às semanas que eu gastava tentando reconstruir a arquitetura mentalmente.
Outra técnica que eu uso frequentemente é o espelhamento de comportamento. Você cria um teste de integração que apenas observa o que acontece quando o sistema é acionado. Não assume o que deve acontecer. Apenas registra. Isso revela coisas que o código não mostra. Tipo um timeout de rede que nunca é tratado, ou uma conversão de tipo que faz o valor zero desaparecer silenciosamente em certas condições de borda. Eu descobri um bug desses em um sistema financeiro usando exatamente esse método. O erro só aparecia quando o saldo era múltiplo de treze. Ninguém tinha notado porque a carga de teste nunca usava esse tipo de dado.
Quando isso funciona e quando você deve fugir
O conhecimento tácito descrito pela expressão nao sei so sei que foi assim funciona bem em sistemas pequenos, estáveis e com baixo turnover. Quando o time é reduzido e as mudanças são raras, alguém pode manter o controle mental do sistema por anos sem documentazione formal. Isso acontece em muitas empresas de pequeno porte. O problema é que essa abordagem colapsa rapidamente quando o sistema cresce ou quando o responsável sai. A verdadeira armadilha é confundir conhecimento tácito com falta de esforço. Às vezes o código é realmente ruim e só funciona porque ninguém mexe. Nesse caso, qualquer tentativa de entender vai te levar a conclusões erradas. Eu perdi quatro dias tentando entender um módulo de cálculo de impostos porque o desenvolvedor original tinha feito uma gambiarra com casting de ponteiro que só funcionava em ambiente de 64 bits. A documentação era inexistente e os comentários eram enganosos. O único caminho foi escrever um programa de testes que variava um parâmetro de cada vez até encontrar o padrão. Isso levou uma semana, mas salvou o projeto.
Se você estiver em uma situação onde o sistema está crescendo rápido e ninguém sabe explicar o funcionamento interno, a recomendação honesta é não tentar documentar tudo. Foco nos pontos de falha. Mapeia os caminhos críticos que, se quebrarem, derrubam a operação. O resto pode esperar. Isso reduz o tempo de compreensão inicial de algo como vinte horas para cerca de seis horas, dependendo da complexidade do sistema.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O caso do deployment que ninguém entendia
Um exemplo específico que eu tive foi num sistema de logística onde o deployment envolvia executar um script shell chamado deploy.sh sem explicação. O script rodava comandos em sequência, mas a ordem importava e mudar qualquer linha quebrava tudo. Eu passei três dias rastreando o que acontecia em cada etapa usando logging explícito adicionado temporariamente. O resultado foi que o script fazia três coisas principais: atualizava o banco, reiniciava o serviço de cache e disparava uma fila de processamento. A ordem era essencial porque o serviço de cache assumia dados antigos se o banco ainda não tivesse sido atualizado. Não existia documentação disso. Nem nos comentários do script, nem em nenhum repositório interno. A única pista era um commit antigo com a mensagem fix orden que ninguém conseguia contextualizar. Quando o novo engenheiro de infraestrutura chegou e tentou adaptar o processo para Kubernetes, o deployment falhou silenciosamente porque o sidecar de cache iniciava antes do banco estar pronto. Ele gastou dois dias debugging até perceber que a ordem de inicialização dos pods era o problema. Isso poderia ter sido evitado com um README de cinquenta linhas, mas o conhecimento nunca foi compartilhado.
Como transformar isso em vantagem
Em vez de ver o conhecimento tácito como um problema, eu aprendi a tratá-lo como um ativo que precisa ser preservado. A técnica que uso é a sessão de engenharia reversa documentada. Você escolhe um membro do time que conhece o sistema, mesmo que não consiga explicar academicamente, e grava uma sessão de dez minutos enquanto ele resolve um bug real. Não pede teoria. Pede ação. Anota cada decisão, cada hipótese testada, cada solução alternativa descartada. Esse material vira a base do que seria a documentação que nunca existiu. O processo leva cerca de quatro horas por módulo crítico, incluindo gravação, transcrição básica e organização. O retorno é proporcional. Sistemas que antes levavam semanas para serem compreendidos por novos integrantes passam a ser entendidos em dias. A maior limitação é que isso depende de alguém no time ter esse conhecimento acumulado. Se o departamento inteiro funcionar no principio do nao sei so sei que foi assim sem registro algum, o trabalho duplica porque você precisa reconstruir o entendimento a partir do comportamento observado, não da intenção original.
Outra técnica útil é o uso de testes de smoke como documentação executável. Quando você identifica um comportamento crítico, escreve um teste automatizado que valida exatamente aquele cenário. O teste vira a especificação viva do sistema. Isso é especialmente válido para casos de borda que só aparecem em produção. Eu construí uma suíte de quarenta e dois testes de smoke que cobriam os cenários mais estranhos que já haviam quebrado o sistema nos últimos três anos. Cada teste tinha um comentário explicando qual problema histórico ele resolvia. Esse conjunto reduziu drasticamente a probabilidade de regressão e serviu como guia para quem precisava entender o sistema rapidamente.
O problema dos sistemas que só funcionam sob condições específicas
Toda vez que eu vejo um sistema descrito como nao sei so sei que foi assim, logo penso nas condições ocultas que o mantêm funcionando. Horários do dia, volume de dados, presença de arquivos específicos no disco, variáveis de ambiente não documentadas. Num projeto meu, o sistema de relatórios só gerava saída correta entre 2h e 4h da madrugada porque um processo batch atualizava tabelas intermediárias nesse período. Fora dessa janela, os dados estavam inconsistentes. Nenhum aviso era dado. O relatório simplesmente retornava valores errados sem indicação de erro. Eu descobri isso medindo o tempo de resposta do endpoint de geração de relatório ao longo de vinte e quatro horas. O padrão era claro. Horas úteis, tempo médio de resposta era de doze segundos com dados incorretos. Janela noturna, tempo caía para dois segundos com dados corretos. A diferença estava no job agendado que ninguém mais lembrava que existia. Esse tipo de descoberta exige observação sistemática, não leitura de código. Leitura de código nesse cenário é perda de tempo porque a lógica não está no código, está no contexto operacional.
Quando vale a pena investir em documentação
A resposta curta é quando o custo de substituir o conhecimento tácito for menor do que o custo de perder o sistema. Na prática, isso acontece quando o time tem rotatividade prevista, quando o sistema precisa ser escalado, ou quando compliance exige rastreabilidade. Se nenhuma dessas condições existir, o investimento em documentação formal pode ser desperdício. Eu já vi times documentarem sistemas que seriam substituídos em seis meses. O trabalho foi inútil porque a arquitetura nova era completamente diferente. O equilíbrio que eu recomendo é documentar apenas os pontos de decisão crítica. Não o código, mas as razões pelas quais escolhas foram feitas. Por que esse timeout foi definido como trezentos milissegundos? Por que essa tabela não tem índice? Por que esse serviço depende de um arquivo que não está no repositório? Três linhas por decisão crítica são suficientes para o próximo engenheiro entender o raciocínio sem precisar recriar tudo do zero. Isso reduz o tempo onboarding de novos membros de semanas para dias, dependendo da complexidade.
A versão brasileira do problema
No Brasil, o fenômeno do nao sei so sei que foi assim tem características culturais específicas. A tendência é evitar questionar o conhecido como funciona porque gerar atrito é mal visto. Um engenheiro junior raramente pergunta por quê para um sênior, mesmo quando percebe inconsistência. O resultado são sistemas com decisões obscuras legitimadas por hierarquia, não por mérito técnico. Eu já participei de reuniões onde uma configuração ruim era mantida porque o gestor disse que sempre foi assim, sem possibilidade de revisão. O workaround que eu encontrei foi introduzir a prática de postmortem técnico sem culpa. Em vez de culpar alguém pelo desconhecimento, o time analisa o sintoma e propõe hipóteses. Isso cria um espaço seguro para questionar o estabelecido sem confrontar pessoas. O processo leva cerca de uma hora por incidente crítico e gera registros úteis que podem ser convertidos em documentação incremental. O efeito colateral positivo é que a equipe passa a documentar naturalmente, sem percepção de burocracia.
Em resumo, lidar com sistemas que operam no principio do nao sei so sei que foi assim exige paciência, observação e documentação seletiva. Não adianta querer entender tudo. Foco no que quebra, registra o comportamento observado e constrói proteções ao redor dos pontos críticos. O resto pode aguardar. Sistemas assim nunca serão totalmente compreendidos, mas podem ser gerenciados com risco controlado se você investir tempo nos lugares certos.
