Herdei 200 mil linhas de código espaguete: os 7 primeiros dias, na ordem em que eu faço

Herdou código espaguete? A ordem dos 7 primeiros dias: o que medir antes de escrever uma linha, o que congelar e como transformar isso em três prazos para o conselho.

Antes de abrir o editor, a primeira semana é passada lendo o que o sistema fez ontem

Herdar 200 mil linhas de código espaguete tem uma ordem, e ela começa longe do editor. Nos dois primeiros dias você mede o que o sistema fez ontem: quais rotas o mundo real chamou, quais jobs rodaram, quais tabelas alguém escreveu. No terceiro, tenta subir tudo numa máquina limpa e cronometra. No quarto, lê o histórico do repositório em vez de procurar documento. No quinto, abre a suíte de testes para contar quantos verificam alguma coisa. Nos dois últimos, você escreve duas listas: o que já dá para prometer e o que está proibido de tocar.

A proibição da primeira semana é curta e vale mais que o resto: nada de refatorar, nada de trocar biblioteca, nada de "aproveitar que estou aqui". A única mudança aceitável nesses sete dias é a que torna o sistema observável, ou seja, log, medição, alarme. Você ainda não sabe o que quebra, e código espaguete quebra em lugar que não tem relação nenhuma com o arquivo que você abriu.

A pergunta "herdei 200 mil linhas de código espaguete, e agora?" está no Stack Exchange desde 2012, com 463 de pontuação, 19 respostas e mais de 200 mil visualizações. As respostas de lá são boas para o desenvolvedor que vai abrir o editor. Elas não ajudam quem vai responder ao conselho na sexta-feira. O que segue é a ordem que eu uso quando entra um resgate desses, escrita para quem tem que dar satisfação sobre prazo e dinheiro.

Dias 1 e 2: descubra o que o sistema fez ontem, não o que ele foi feito para fazer

O tempo de subir o sistema numa máquina limpa é o termômetro mais barato que existe

O código diz o que alguém quis construir. O log diz o que o negócio realmente usa. A distância entre os dois é quase sempre grotesca, e é ela que decide onde você vai gastar os próximos três meses.

Quatro medições cabem em dois dias e não exigem entender uma linha do sistema:

• Agrupe os acessos dos últimos sete dias por rota e ordene por volume. Em quase todo resgate que chega aqui, um punhado de rotas responde por mais de 80% das chamadas, e o restante do sistema é museu.
• Rode um `select max(updated_at)` em cada tabela grande. Tabela sem escrita há dois anos é funcionalidade morta que ninguém teve coragem de desligar.
• Liste o que roda por agendamento (cron, fila, scheduler) e o horário de cada um. É aqui que mora o processo noturno que ninguém documentou e que derruba tudo quando você mexe no lugar errado.
• Pegue os cinco erros mais frequentes em produção nos últimos trinta dias. Se não existe ferramenta de erro instalada, essa é a sua primeira entrega, e ela leva umas duas horas.

Numa dessas leituras eu achei um endpoint chamado 11 mil vezes por dia por um cliente que tinha encerrado contrato fazia meses. O robô dele continuava batendo, o servidor continuava respondendo, e ninguém sabia. Desligar aquilo derrubou uns 30% do custo de banco sem tocar em nenhuma regra de negócio.

Isso é vistoria de estrutura antes de furar parede. Você não descobre onde passa a coluna lendo o projeto original, porque o projeto original mudou três vezes na obra e ninguém redesenhou.

Dia 3: cronometre o setup numa máquina limpa

Pegue um computador sem nada instalado e tente subir o sistema do zero, seguindo apenas o que está escrito no repositório. Anote o relógio e anote cada coisa que faltou: variável de ambiente que ninguém citou, versão de runtime que só existe na máquina do dev antigo, dump de banco que alguém guardou no Drive pessoal.

Esse número é o melhor termômetro de saúde que existe, e é barato de obter. Se leva quarenta minutos e três perguntas no WhatsApp, o sistema está vivo. Se leva dois dias e depende de uma pessoa específica, você não herdou um sistema, você herdou uma dependência humana. E o que você acabou de anotar já é o primeiro documento verdadeiro do projeto, escrito por quem sentiu a dor.

O mesmo vale para o caminho de saída. Já herdei um deploy de 50 minutos e considerei aquilo boa notícia, porque deploy lento é problema de encanamento, com conserto conhecido e prazo estimável. Deploy que ninguém sabe reproduzir é outra categoria.

Dia 4: o histórico do repositório é a documentação que ninguém consegue deixar de atualizar

A lista do que está proibido tocar vale mais que qualquer plano de refatoração no dia 7

Documento mente porque para de ser atualizado. Commit não mente, porque atualizar é condição para o código existir.

O comando que eu rodo primeiro lista os arquivos mais alterados nos últimos doze meses. Os vinte primeiros são o sistema de verdade: é ali que o negócio muda, é ali que a regra vive, é ali que você vai passar o ano. Se um arquivo de 4 mil linhas chamado `utils` aparece no topo, você já sabe qual é a casca podre e já sabe por que toda alteração pequena vira uma semana.

Depois eu olho quem escreveu. Quando 70% dos commits do último ano são de uma pessoa só, e essa pessoa saiu, o risco não está no código, está na agenda. Quando são de oito fornecedores diferentes em dezoito meses, o padrão é outro: cada um resolveu o próprio pedaço do jeito que sabia, e agora convivem três formas de acessar o banco no mesmo repositório. Isso é dívida que não aparece em nenhum relatório de ferramenta, é a dívida cognitiva que mora fora do código, na cabeça de quem foi embora.

Dia 5: conte quantos testes verificam alguma coisa

Cobertura de teste é o número mais fácil de falsificar do mercado. Já abri repositório com 92% de cobertura em que boa parte dos arquivos de teste não tinha uma única asserção. O teste chamava a função, a função não explodia, a linha era contada como coberta. Isso é teatro de qualidade: a métrica existe, a garantia não.

O irmão gêmeo disso é o monitoramento sem instrumentação, o famoso `/health` que devolve 200 porque foi programado para devolver 200. O painel fica verde enquanto o banco está fora do ar.

No quinto dia você não conserta nada disso. Você conta. Quantos arquivos de teste existem, quantos têm asserção, quanto tempo a suíte leva, quantos testes estão marcados para pular. Esse inventário é o que vai dizer, mais tarde, se dá para automatizar revisão. Ferramenta ajuda no óbvio, e eu já escrevi sobre onde a revisão de código por IA substitui humano e onde não substitui, mas nenhuma delas sabe qual regra de negócio aquele `if` de 2019 estava protegendo.

Dias 6 e 7: escreva o que você se proíbe de tocar

A lista de proibição é o entregável mais valioso da semana, e é ela que salva o segundo mês. Ela tem três linhas, e cada linha precisa de um motivo escrito:

1. O arquivo mais alterado do repositório fica congelado até existir teste em volta dele. É onde o negócio vive e onde qualquer mudança sua vai ser percebida por um cliente.
2. Nada de trocar biblioteca, framework ou versão de banco nesta rodada. Subir MySQL 5 para 7 e trocar para Postgres parecem a mesma tarefa para quem olha de fora. São banana prata, banana nanica e maçã: todas frutas, mas a maçã é outra fruta, com outro prazo e outro risco.
3. Nenhum código morto sai antes de você ter o log de uso. A rota que parece abandonada é justamente a que o financeiro roda uma vez por mês, no fechamento.

O que você pode fazer nesses dois dias é o oposto de refatorar: instrumentar. Colocar log estruturado nas cinco rotas que mais rodam, ligar captura de erro, criar um alarme para o job noturno que falha calado. É mudança aditiva, não destrutiva, e no mês que vem ela é a diferença entre diagnosticar em uma tarde e adivinhar por uma semana.

"Isso é uma semana sem entregar nada"

É a objeção que eu mais ouço, em geral na voz de quem já pagou três fornecedores. Ela tem fundamento e tem resposta.

Essa semana entrega quatro coisas que ninguém na empresa tinha: o mapa do que o sistema realmente usa, o tempo de setup numa máquina limpa, a lista dos arquivos onde o negócio vive e o inventário honesto de testes. Com isso na mão, a resposta que o CEO pede na sexta deixa de ser um chute. Ela vira três prazos separados: quanto tempo para parar o sangramento visível, quanto para descobrir a origem dele, quanto para tratar a doença. O primeiro costuma ser de dias, o segundo de semanas, o terceiro é remédio de meses. Quem promete um número só está escondendo dois.

E tem o efeito colateral que importa para quem contrata: um time que passa a primeira semana medindo é um time que não vai pedir reescrita no terceiro mês. Reescrita é o pedido padrão de quem nunca entendeu o sistema e precisa esconder isso atrás de um projeto novo. Nosso roteiro de entrada de squad externo em 14 dias nasceu exatamente de contar quantas vezes esse pedido apareceu.

Onde essa ordem falha

Ela não serve para sistema que está caindo agora. Se o checkout está fora do ar e a empresa perde dinheiro por hora, você inverte tudo: estanca primeiro, mede depois, e aceita que vai trabalhar às cegas por alguns dias. Também não serve bem para base pequena, coisa de 8 ou 10 mil linhas, onde ler o código inteiro leva menos tempo que montar o instrumento de medida.

Fora esses dois casos, eu não conheço atalho. A pergunta que fica para a sua empresa é mais curta que este artigo: se a pessoa que mais commitou no seu repositório no último ano pedisse demissão hoje, quantos dias você levaria para descobrir o que ela sabia?