Tem empresa em que o problema não aparece quando você abre o código.
Ele aparece quando alguém tenta consertar o básico e ouve que isso é “arriscado”.
Foi esse o centro de um relato publicado no Hacker News por um desenvolvedor com mais de 13 anos de experiência que entrou havia só um mês numa startup já lucrativa e com 10 anos de estrada. Segundo ele, a empresa estava migrando aos poucos de AngularJS para React, carregava um cliente com cerca de 20 MB de JavaScript, mantinha a base em 90% JavaScript e 10% TypeScript e barrava até portar trechos existentes para TypeScript.
Até aí, ainda dava para chamar de legado pesado. O ponto em que a história muda de categoria vem depois.
o detalhe que muda tudo não é o tamanho do caos
De acordo com o relato, o desenvolvedor percebeu erros básicos logo na entrada. Um deles: o repositório não versionava package-lock.json. Ele abriu um PR para corrigir isso. O PR foi recusado porque seria “riscado”.
Aí veio o segundo sinal. Quando o lockfile entrou no fluxo, o npm audit apontou 60 vulnerabilidades críticas. Segundo o autor do post, a resposta de novo foi a mesma: mexer nisso seria “arriscado demais”. Ele também sugeriu pelo menos adicionar uma Content Security Policy por causa do risco de injeção. A resposta continuou igual.
Isso importa porque, na documentação oficial do npm, package-lock.json não aparece como detalhe cosmético. O arquivo existe para garantir instalações idênticas entre time, deploy e CI, além de dar visibilidade real às mudanças na árvore de dependências. E o próprio npm audit depende de package.json e package-lock.json para gerar o relatório de vulnerabilidades.
Em português claro: recusar lockfile e ignorar o audit não é só “cada time tem seu jeito”. Em muitos casos, é escolher operar com menos previsibilidade e menos visibilidade do que o mínimo razoável.
legado ruim ainda é consertável. cultura ruim é o que bloqueia a higiene
O relato fica mais pesado porque o resto da operação segue o mesmo padrão.
Segundo o autor:
- o hot reload levava 30 segundos;
- ele abriu um PR usando Rspack no fluxo de desenvolvimento para cortar esse tempo pela metade, e foi recusado;
- não havia testes automatizados;
- não havia CI;
- a validação ficava num pre-commit hook e numa equipe manual de QA antes das releases;
- no cliente, não existia observabilidade, nem taxa de erro, nem tempo de carregamento;
- quando algo escapava, a lógica era simples: “se o cliente reclamar, a gente corrige”.
Nenhum desses pontos, isoladamente, é inédito em empresa de produto que cresceu torta. O que acende o alerta é o padrão: toda tentativa de reduzir atrito, risco operacional ou cegueira técnica foi tratada como ameaça.
É aí que vale separar duas coisas que muita equipe mistura.
Dívida técnica é quando a casa está bagunçada, mas ainda existe abertura para arrumar.
Dívida cultural é quando a própria organização passa a defender a bagunça como se ela fosse prudência.
o momento mais honesto do caso veio na conversa com o gestor
O fechamento do relato é o que transforma a história em algo maior do que um desabafo sobre código legado.
Segundo o desenvolvedor, o gestor chamou uma 1:1 para dizer que ele não deveria tentar contribuir fora dos tickets designados e que era esperado 1 PR por dia, senão ele poderia ser dispensado.
Esse pedaço é importante porque explica a lógica inteira do sistema.
O objetivo ali aparentemente não era melhorar fluxo, reduzir risco, acelerar feedback nem aumentar compreensão da base. O objetivo era produzir ticket fechado em cadência previsível. Quando a métrica local vira mais importante do que a saúde do sistema, a engenharia começa a performar velocidade enquanto empurra fragilidade para frente.
Nos comentários, muita gente leu o caso como sinal claro de fuga. Outros lembraram que entrar criticando tudo no primeiro mês também costuma gerar resistência política. As duas coisas podem ser verdade ao mesmo tempo.
Só que existe uma diferença entre “o time ainda não confia em você” e “o time já te avisou que não quer mexer em nada estrutural”.
como reconhecer quando o problema deixou de ser só técnico
Se você entra num projeto ruim, normalmente os primeiros sinais são conhecidos: código confuso, build lenta, dependência velha, teste faltando, documentação curta.
Quando o problema é mais fundo, aparecem sinais de outra família:
1) higiene básica passa a ser tratada como ameaça
Lockfile, audit, CSP, CI, observabilidade e testes não entram como luxo. Entram como superfície mínima de controle. Se tudo isso é rotulado como risco por padrão, o recado não é “agora não”. O recado é “não queremos tocar na estrutura”.
2) a empresa terceiriza feedback para o cliente
Quando o monitoramento real é substituído por “o cliente avisa”, o time deixa de observar o sistema e passa a reagir ao constrangimento.
3) velocidade vira teatro de output
Exigir 1 PR por dia pode até soar objetivo. Mas, num ambiente em que melhoria estrutural é proibida, isso tende a premiar só movimentação aparente.
4) ninguém quer pagar o custo da transição
Migrar de JavaScript para TypeScript, colocar CI, criar suíte de testes ou melhorar DX custa energia no curto prazo. Cultura boa discute prioridade. Cultura ruim transforma qualquer investimento em tabu.
a dúvida do autor era honesta — e muita gente em TI já teve a mesma
A pergunta do post era simples: “sou eu que estou implicando com coisa sem importância ou essa cultura é ruim mesmo?”
Esse tipo de dúvida pega porque muita gente em TI aprendeu a normalizar ambiente torto. Principalmente depois de passar por startup, corrida por impacto, stack ranking e pressão por entrega visível.
Só que existe um ponto em que parar para questionar não é preciosismo. É sanidade profissional.
Base ruim existe em todo lugar. Time que desincentiva qualquer melhoria básica também existe. O problema é quando os dois se juntam — e ainda tentam vender isso como maturidade operacional.
o corte mais útil para quem entrou num time assim agora
Nem todo projeto bagunçado é caso perdido. Nem todo novo funcionário deve sair refatorando tudo em 30 dias.
Mas se você encontrou um ambiente em que:
- previsibilidade é tratada como risco;
- segurança fica para depois por tempo indefinido;
- observabilidade só entra quando o cliente reclama;
- melhoria fora do ticket é vista como desvio;
- e throughput vale mais do que entendimento do sistema,
então a pergunta principal talvez não seja “como consertar esse legado?”.
Talvez seja: existe espaço real para melhorar aqui ou a empresa já decidiu que prefere conviver com o dano?
Essa resposta muda bastante o que vale fazer com a sua energia.
