Lemos 31 bases de código que chegaram quebradas. Os números se repetem.

Toda vez que a Revin entra pra resgatar um projeto, a primeira coisa é ler o código de fora pra dentro. Juntei o que encontramos em 31 dessas leituras nos últimos 18 meses: cobertura de teste, deploy, segredo exposto, quem entende o quê. A amostra é torta de propósito, e talvez por isso seja útil.

Por Raquel Reis

Raquel Reis

Toda vez que a Revin é chamada pra resgatar um projeto, a primeira coisa que a gente faz não é escrever código. É ler o que já existe, de fora pra dentro, do jeito que um estranho leria. Essa leitura inicial tem até nome aqui dentro, Diagnostic Sprint, e nos últimos dezoito meses ela rodou em algumas dezenas de bases. Resolvi sentar e somar o que apareceu em trinta e uma delas.

Antes de qualquer número, o aviso honesto: essa amostra é torta de propósito. São projetos que chegaram até nós já doendo, e quem procura resgate não procura elogio. Então não leia isto como "o estado médio do software brasileiro". Leia como um raio-x de onde as coisas quebram quando quebram. Curiosamente, é justo esse recorte enviesado que deixa o padrão tão visível.

Se você vai contratar quem constrói ou mantém seu software, esses quatro números são um bom checklist do que perguntar antes de assinar. Não pra desconfiar de todo mundo, mas pra saber onde olhar.

A gente não começa pelo roadmap nem pela reunião. Começa por aqui: lendo, linha por linha, o que já foi construído.

Os quatro números

Resumindo o que trinta e uma leituras devolveram, com os números arredondados sem dó, porque amostra desse tamanho não comporta casa decimal:

• Cobertura de teste: em 71% das bases, menos de um quinto do código tinha qualquer teste automatizado.
• Deploy: 6 em cada 10 dependiam de um deploy manual, tocado da máquina de uma pessoa específica.
• Segredo exposto: 1 em cada 3 guardava credencial de produção em texto puro, versionada no histórico do Git.
• Conhecimento concentrado: em 22 das 31, mais da metade do sistema só uma pessoa entendia de verdade.

Nenhum desses números é exótico. Cada um, sozinho, é o tipo de canto que dá pra justificar com um "a gente arruma depois". Juntos, contam outra história, e é dessa história que vale falar.

O que os números não dizem sozinhos

Cobertura baixa raramente é preguiça. É o que sobra quando alguém é pago pra entregar tela e ninguém é pago pra garantir que a tela continue de pé daqui a seis meses. Teste não aparece na demo. Deploy bem feito também não. O que aparece é a próxima feature, e é nela que o dinheiro do fornecedor está.

O deploy manual é o meu favorito da lista, porque é quase sempre a mesma cena. Numa das auditorias, de um e-commerce com faturamento na casa dos sete dígitos, o deploy de produção era um script rodado do notebook de um único desenvolvedor. Notebook que ia pra casa com ele toda noite e pra praia no feriado. Quando esse dev tirava férias, a empresa congelava na prática. Ninguém tinha decidido que seria assim. Foi só virando, sprint após sprint, sem ninguém olhar.

É esse tipo de coisa que o Diagnostic Sprint coloca na mesa em duas semanas, antes de virar crise. E pra quem gosta de número, a gente já tinha publicado um benchmark de tempo de review de PR na mesma linha de medir o que costuma ficar invisível.

O segredo que ninguém tinha trocado

Aquele 1 em cada 3 com credencial à mostra é o número que mais assusta o cliente quando aparece na tela, e o que menos surpreende a gente. A chave entra no código num commit de pressa, funciona, e fica. Ninguém troca porque ninguém lembra que ela está ali. Escrevi semana passada sobre por que isso é hábito, e não azar, em segurança não é uma feature, é um jeito de trabalhar.

Os números só viram diagnóstico quando alguém para pra olhar de perto. É literalmente o trabalho.

O padrão por trás do estrago

Olhando as trinta e uma juntas, o que une elas não é uma tecnologia, nem um setor, nem um time incompetente. Quase todo mundo ali era gente boa. O que une é o modelo de quem construiu: software feito por quem foi pago por entrega e foi embora. O freela que rodou três meses e sumiu, a agência que fechou o escopo e nunca mais voltou, o fornecedor que trocava de dev sem repassar contexto. Ninguém ficou tempo suficiente pra que a casa importasse depois da mudança.

É bem esse o buraco que um squad embarcado preenche, e não por talento maior. É por ficar. Quando o time que escreve a feature é o mesmo que vai mantê-la daqui a um ano, o teste deixa de ser custo e vira autopreservação. O deploy manual, idem: ninguém quer rodar à mão, toda semana, uma coisa que dá pra automatizar uma vez. E aquele segredo no repositório vira problema de alguém que ainda vai estar por ali quando ele vazar. A continuidade muda o incentivo, e o incentivo muda o código.

No fim, o que me chamou atenção nessas trinta e uma leituras não foi a gravidade de cada caso. Foi a repetição. Os mesmos quatro buracos, em ordens diferentes, projeto atrás de projeto. E o que se repete tanto assim não é azar, é estrutura. Estrutura dá pra prever, e o que dá pra prever dá pra evitar.

Se você quer ver esse padrão sendo desfeito na prática, os cases contam melhor que eu. E se você desconfia que a sua base esconde dois ou três desses números, é bem mais barato descobrir agora, com a gente, do que no meio de uma crise. Quando quiser, marca uma conversa.