Dívida técnica e segurança: por que a varredura automática acha o furo antes do seu time

Dívida técnica saiu da fila de sprint e virou exposição: código antigo é o primeiro lugar que a varredura automática lê. Três medidas para priorizar o que arrumar.

O arquivo que ninguém abre desde 2011 continua respondendo a quem chama de fora.

Dívida técnica saiu da fila de sprint e entrou na conta de risco da empresa. Até pouco tempo, aquele arquivo de 2011 que ninguém abre era um problema de prazo: atrasava a tela nova, irritava o time, voltava na retrospectiva e dormia no backlog. Hoje ele é o primeiro lugar onde uma varredura automática entra, e essa varredura roda em minutos, todo dia, sem cansar.

A resposta prática, antes de qualquer argumento: liste os pontos do seu sistema que o mundo de fora alcança e que quase não mudaram nos últimos três anos, descubra quais deles têm teste que verifica alguma coisa de verdade e erro que chega em alguém acordado, e só então discuta refatoração. Nessa ordem. Refatorar antes dessas duas respostas é rebocar parede com infiltração atrás.

A conta de 40 anos chegou toda no mesmo mês

Painel colorido em cima de dado vazio é a parte mais cara: você passa meses achando que está coberto.

Um texto da IEEE Spectrum dizendo que a IA está nos forçando a pagar 40 anos de dívida técnica fez 1.309 pontos e 750 comentários no Hacker News. Quem acompanha aquele fórum sabe que esse volume não é rotina. É o número que aparece quando muita gente reconhece o próprio sistema na descrição e desce para comentar.

O mecanismo é simples e desconfortável. O que protegia o seu código antigo não era a qualidade dele, era o custo de alguém olhar. Auditar algumas centenas de milhares de linhas de um sistema parado desde 2014 custava semanas de gente caríssima, então ninguém olhava, nem o seu time nem quem queria entrar. Esse custo caiu para o preço de uma assinatura mensal. A dívida ficou do mesmo tamanho, o preço de encontrá-la é que despencou.

A pergunta de como medir isso também não é nova. No Stack Exchange, a pergunta de como quantificar a dívida técnica de um projeto passou de 20 mil visualizações, e a de como convencer a diretoria a tratar o assunto tem 176 pontos e perto de 19,5 mil leituras. Engenharia pede isso há mais de dez anos, com planilha e tudo. Mudou quem pede junto: o questionário do seguro, o cliente grande que manda uma lista de verificação antes de assinar, e agora uma ferramenta que varre sozinha e não precisa de autorização de ninguém.

Se você precisa levar o assunto para uma reunião de sócios, traduza em três colunas: o que a empresa perde se aquele pedaço parar por um dia, quanto custa arrumar agora, quanto custa arrumar depois de um incidente. É a diferença entre uma queixa de desenvolvedor e uma planilha de risco com custo, prazo e receita na mesma linha.

A sua dívida velha também atrapalha a sua IA

O InfoQ publicou nesta semana que engenheiros do Google descreveram um efeito batizado de agent distraction. Agente de código que entra numa base cheia de dívida antiga se perde no caminho: comentário de TODO escrito em 2017, referência a um bug fechado há anos, especificação desatualizada que contradiz o código ao lado. O agente lê aquilo como instrução e sai fazendo tarefa que ninguém pediu.

Guarde essa parte, porque ela cobra nas duas pontas. A mesma bagunça que te expõe por fora derruba o retorno da ferramenta que você comprou para acelerar por dentro. E boa parte dessa bagunça nem está no código: está no que só existe na cabeça de duas pessoas, aquilo que eu chamo de dívida cognitiva. Spec desatualizada é dívida cognitiva com carimbo de documento oficial.

"A gente arruma quando sobrar sprint"

A fila de prioridade sai de uma tarde olhando o sistema rodando, não o repositório.

Essa frase saiu da minha boca em quase toda reunião de produto que eu fiz na minha primeira empresa, uma startup de locação de equipamento para construção civil. Eu contratava desenvolvedor sem saber julgar o que me respondiam e tratava dívida técnica como desejo do time, coisa de quem quer o código bonito. O que eu não enxergava é que a fila nunca sobra. Sprint sobra zero vez. E o que eu empurrei virou o motivo pelo qual, meses depois, trocar uma regra de preço passou a custar três semanas.

Hoje eu estou do outro lado do balcão e recebo a mesma frase por e-mail, escrita por founders que não têm culpa nenhuma de acreditar nela. O vilão aqui não é o time nem o fornecedor de plantão, é o modelo de contratação. Preço fechado sem previsão de continuidade incentiva entregar casca podre e virar as costas, porque a conta da manutenção vai cair no colo de outra pessoa. Quando o incidente chega, o telefone que toca é o seu.

Teste que não testa, monitoramento que não instrumenta

Nos resgates que a gente pega depois que uma fábrica de software vira as costas, três coisas aparecem quase sempre: query lenta encadeada com outra query lenta, cobertura de teste alta sem um expect dentro do arquivo, e monitoramento que é um endpoint de health respondendo 200 sem tocar no banco, com painel colorido em cima de dado vazio.

Isso é teatro de qualidade. A métrica existe, a garantia não. E o caro não é o furo em si, é o tempo que você passa acreditando que está coberto. Pelo que eu vejo, uns 40% do primeiro mês de uma squad dentro de um sistema desses vai só para descobrir o que ele de fato faz quando alguém aperta o botão. Já abri base em que o processo mais importante do negócio rodava num agendamento que existia na máquina de uma pessoa e não no repositório. Voltando ao ponto: antes de corrigir, a gente mede quantos erros deram ontem, em quais rotas e para quantos clientes, que é exatamente o roteiro das duas primeiras semanas num sistema sem documentação.

Três medidas antes de alguém abrir o editor

1. Superfície que o mundo alcança: liste rotas, formulários, uploads e integrações que recebem chamada de fora e cruze cada uma com a data da última alteração do arquivo. O que está exposto e parado há três anos vai primeiro na fila, mesmo que o código pareça inofensivo.
2. Verificação de verdade: pegue os três arquivos mais críticos dessa lista e quebre uma regra de propósito. Se nenhum teste ficar vermelho, a sua cobertura é número de relatório e você está decidindo no escuro.
3. Dono e aviso: para cada item, escreva o nome de uma pessoa e o canal onde o erro aparece. Dívida sem dono não entra em fila nenhuma, ela só reaparece de madrugada.

Nada aí exige comprar ferramenta. Exige uma tarde e alguém com permissão de olhar o sistema rodando, não o repositório.

Nem toda dívida vale pagar

Um cliente me perguntou se subir do MySQL 5 para o 7 era a mesma coisa que trocar para Postgres. Respondi com a feira: 5 é banana prata, 7 é nanica, Postgres é maçã. As três são fruta, e a maçã é outra fruta. A versão vizinha costuma ser trabalho de semanas com risco mapeado. A troca de banco é projeto novo, com migração de dado, reescrita de query e um time aprendendo no caminho. Se alguém te deu o mesmo prazo para essas duas linhas do orçamento, alguém chutou, e a mesma confusão aparece quando a conversa é migrar PHP 5.6 para 8 ou reescrever do zero.

E eu quase nunca aprovo reescrita do zero, por um motivo chato: a reescrita te devolve o mesmo sistema que você já tinha, meses depois, com bugs novos e com as mesmas regras de negócio que ninguém escreveu em lugar nenhum. Admito o limite do conselho. Não sei dizer se ele vale para uma empresa com duas pessoas de tecnologia e um sistema de poucos milhares de linhas. Ali a conta pode fechar do outro lado, e eu já vi fechar.

O que você pergunta na reunião de segunda

A varredura automática já está rodando e não espera o seu planejamento trimestral. Então faça duas perguntas na próxima reunião de status: qual é o pedaço do nosso sistema que atende gente de fora e ninguém encosta desde 2021, e quem é avisado quando ele falha?

Se as duas respostas levarem mais de um dia para aparecer, a sua dívida técnica já saiu da pauta de engenharia. Ela está na sua, e a data de vencimento quem marca é outra pessoa.