Dívida técnica no front-end: os sinais de que o código ficou caro de mudar

Sinais que o gestor percebe antes do time admitir

Dívida técnica no front-end é o custo extra que cada mudança passa a carregar por decisões de código que foram boas o bastante no começo. Ela não aparece numa métrica única. Reconhece-se pelo comportamento do time e do produto: o que antes levava um dia agora leva uma semana, e ninguém sabe dizer exatamente por quê.

A boa notícia é que a dívida se paga em etapas, com entrega a cada uma, sobre o código que já está em produção. Antes, porém, é preciso reconhecê-la. Quem acompanha o produto de fora costuma ver três sinais.

A mudança simples que leva semanas

Trocar um texto, ajustar um campo de formulário, mudar a cor de um botão em todas as telas. O pedido parece pequeno, mas a estimativa volta grande. O motivo quase nunca é o pedido: é o que o time precisa descobrir, conferir e testar à mão antes de mexer.

Uma cena ilustrativa: o gestor pede para alterar o rótulo de um botão que aparece em várias telas. O time responde que precisa de dias, porque o mesmo botão foi copiado e alterado em cada tela, e ninguém sabe quantas versões existem.

A correção que quebra outra tela

Corrige-se um defeito na tela de cadastro e, dois dias depois, a tela de relatório apresenta outro. Isso indica que partes do código dependem umas das outras de um jeito que não está escrito em lugar nenhum. A regressão deixa de ser exceção e vira rotina, e a confiança na entrega cai.

O arquivo em que ninguém quer mexer

Em quase todo codebase antigo há um arquivo assim. Grande, sem testes, escrito por alguém que já saiu. O time contorna: acrescenta código ao redor, em vez de alterar o que existe. Cada contorno torna o arquivo mais difícil de entender, e o medo cresce junto.

O sintoma é de estrutura, não de pessoa. Times competentes chegam a esse ponto quando o código cresceu mais rápido do que a organização dele. Tratar como falha individual só esconde a causa e atrasa a correção.

De onde vem a dívida no front-end

A dívida raramente nasce de descuido. Em geral vem de três origens, e reconhecer qual delas pesa mais ajuda a decidir o que fazer primeiro.

Uma decisão razoável que ficou para trás

No começo, copiar um componente e ajustar era o caminho mais rápido, e o prazo pedia rapidez. A decisão estava certa para aquele momento. O que mudou foi o contexto: o produto cresceu, entraram mais pessoas e o atalho virou padrão. A dívida é o custo dessa decisão cobrado agora, em cada mudança.

A mesma interface refeita de vários jeitos

Botão, tabela e formulário aparecem em cada tela com pequenas diferenças de espaçamento, cor e comportamento. Sem uma fonte única, cada ajuste precisa ser repetido em todos os lugares, e sempre sobra algum esquecido.

Quando o problema é esse, a resposta está na camada de interface: um design system, com valores nomeados para cor, tipografia e espaçamento, e componentes reaproveitados. O texto sobre tokens de design explica como esses valores funcionam.

Falta de fronteira e de verificação automática

O terceiro grupo é o mais difícil de ver. Quando qualquer parte do código pode chamar qualquer outra, mexer em um ponto afeta pontos distantes. E quando não há tipos nem testes nos lugares onde um erro sairia caro, a regressão só é descoberta em produção, por quem usa o sistema.

• Acoplamento: partes que dependem do funcionamento interno umas das outras, sem limite claro.
• Ausência de tipos: o código aceita dados no formato errado e só falha na execução.
• Ausência de testes onde importam: não se trata de cobrir tudo, mas de proteger os fluxos em que uma regressão custa mais.

Pagar em etapas sem parar o produto

Parar o roadmap por meses para "arrumar a casa" costuma ser inviável, principalmente em órgão público ou em empresa com produto no ar. O caminho mais seguro é dividir o trabalho em etapas que cabem junto da operação.

Diagnóstico antes de mexer

Comece medindo. Sem medição, a conversa vira opinião: cada pessoa aponta o que mais a incomoda. Os números úteis são o tempo de build, o tamanho do bundle (o JavaScript que o navegador baixa), os pontos de acoplamento e os Core Web Vitals.

Uma ressalva importante: nem toda lentidão nasce no front-end. Servidor, banco de dados e infraestrutura também pesam. O diagnóstico serve justamente para separar o que é de cada camada, em vez de ajustar telas para esconder um problema que está em outro lugar.

Uma etapa em produção antes da próxima

Cada etapa precisa terminar com algo entregue e funcionando. Assim o risco fica contido: se uma mudança der problema, ela é pequena e recente, fácil de localizar. E o ganho aparece cedo, o que sustenta o apoio de quem aprova o trabalho. As mesmas medições do início são repetidas ao fim, para o resultado ser comparado e não apenas declarado.

O combinado que vira verificação automática

Combinar um padrão em reunião não basta, porque o combinado se perde com o tempo e com a troca de pessoas. O que foi decidido deve virar verificação automática: lint para o estilo, tipos para impedir o uso errado e testes para os fluxos críticos, rodando antes de cada mudança entrar. Assim o código novo não recria a dívida que acabou de ser paga.

É esse o desenho do trabalho de arquitetura front-end: diagnóstico com evidência, plano em etapas e implementação junto do time interno.

Qual dívida pagar primeiro

Nem toda dívida merece ser paga, e não há como pagar todas ao mesmo tempo. A pergunta que ordena a fila é: o que mais encarece a próxima mudança?

• Comece pelo que atrapalha o roadmap. Se as próximas entregas previstas passam por uma área difícil de alterar, é ali que o pagamento rende mais.
• Área que muda muito vale mais que área parada. Um módulo feio que ninguém toca há anos pode esperar. Um módulo em que o time mexe toda semana cobra juros toda semana.
• O que causa regressão vem antes do que só incomoda. Código que quebra em produção tem prioridade sobre código apenas desagradável de ler.
• Se o problema é a mesma tela em três versões, o design system entra antes. Reorganizar o código por baixo, com a interface ainda dispersa, só desloca a bagunça de lugar.

Perguntas para levar ao time

Uma conversa curta com quem mexe no código todo dia costuma revelar a ordem certa. Cinco perguntas ajudam:

1. Qual mudança prevista para os próximos meses mais nos preocupa?
2. Em que arquivo ou módulo mexemos com mais medo?
3. Quais telas já quebraram por causa de uma alteração em outro lugar?
4. Quanto do tempo de uma tarefa vai para entender e conferir, e quanto para fazer?
5. Já medimos build, bundle e Core Web Vitals, ou estamos decidindo por impressão?

As respostas mostram onde a dívida custa mais. Para entender como a estrutura se relaciona com a capacidade de crescer, leia também o que é um sistema escalável. E, se o código já está caro de mudar, descreva o cenário para a Evo Tech: o primeiro passo é o diagnóstico, que mostra por onde começar.