A dívida técnica não depende de quem escreveu o código, mas sim do custo de alterá-lo. Um módulo perfeitamente correto que ninguém na equipe entende é dívida técnica, mesmo que não tenha um único bug, porque cada modificação futura exigirá a reconstrução de um raciocínio que ninguém criou.
Isso importa agora mais do que nunca, porque surgiu um caminho rápido para acumular código correto, porém mal compreendido: aceitar o que um modelo gera sem entender por que ele é daquela maneira.
Quando uma equipe modifica um sistema, o trabalho real não é escrever novas linhas de código. É responder a três perguntas antes de escrevê-las: o que isso faz agora, por que é feito dessa maneira e o que vai quebrar se eu mudar.
Esse trabalho se chama compreensão e consome a maior parte do tempo envolvido em qualquer alteração em um sistema maduro. Se ninguém entendeu o código quando ele foi introduzido, essa conta não desaparece: ela é adiada e paga com juros, porque quem a pagar nem sequer terá o contexto da discussão original.
Existe uma assimetria incômoda: Gerar é mais rápido do que compreender.. Um modelo pode produzir em segundos algo que uma pessoa leva vinte minutos para entender. Quando a geração acelera e a compreensão não, o desequilíbrio se acumula no repositório.
Ninguém sabe se uma peça está sendo usada. Aparecem códigos que podem ou não ser necessários e, na dúvida, são mantidos. O sistema fica sobrecarregado com material que ninguém se atreve a apagar.
As avaliações tornam-se superficiais. Quando mudanças significativas ocorrem com frequência, o processo de avaliação passa de "Eu entendo e concordo" para "Isso parece razoável". É uma mudança silenciosa, mas decisiva.
Os mesmos problemas são resolvidos duas vezes. Surgem três funções que fazem praticamente a mesma coisa, porque ninguém sabia da existência das outras.
Os erros são corrigidos envolvendo o conteúdo, não consertando-o. Em vez de resolver o problema, adiciona-se uma condição, porque mexer com o original é assustador.
A GitClear quantificou o terceiro sintoma: blocos de código duplicados aumentaram oito vezes em 2024, e seu relatório subsequente indicou que a duplicação continuou a crescer. A duplicação é a assinatura estatística da incompreensão: as pessoas copiam o que não entendem suficientemente bem para reutilizar de forma eficaz.
Propomos apenas uma, e é fácil de defender em qualquer equipe:
Ninguém mescla código que não conseguiria explicar em um quadro branco.
Não exige compreender todos os detalhes da implementação. Exige ser capaz de responder a três perguntas: que problema resolve, por que foi resolvido desta forma e não de outra, e o que aconteceria se deixasse de existir.
Quando aplicada corretamente, essa regra não atrasa o processo; ela o reordena. Gerar o código 80% com auxílio continua válido. O que não é mais válido é incorporá-lo sem tê-lo lido.
|
Prática |
Antes |
Com geração assistida |
|---|---|---|
|
Tamanho da mudança |
Limitado pelo tempo disponível para escrevê-lo. |
Pode crescer sem limite natural. |
|
Foco da revisão |
Encontrar erros |
Verifique se compreende e se ajusta. |
|
Principal risco |
Uma falha específica |
Aceitar uma estrutura que ninguém decidiu. |
|
Controle eficaz |
Revisão por pares |
Alterar o limite de tamanho e os testes obrigatórios. |
O tamanho das linhas explica a descoberta da DORA em 2024: à medida que a adoção de IA aumentou, a estabilidade de entrega caiu em 7,2%. A causa não é a qualidade do código gerado, mas sim o desaparecimento do fator natural que impede a sua escrita. Uma alteração de mil linhas não é revisada da mesma forma que uma de cinquenta linhas, independentemente da competência do revisor.
Portanto, o controle mais eficaz não é uma ferramenta, mas sim um padrão de processo: limitar a magnitude das mudanças. É simples e funciona.
Testes elaborados por uma única pessoa. É razoável que o modelo gere a implementação; é razoável que ele também gere o teste que valida essa implementação, fechando assim o ciclo. O teste deve expressar o que o negócio espera, e isso é algo que só uma pessoa sabe.
Documentação da decisão, não do código. Não é necessário comentar cada linha. O que é preciso é um parágrafo explicando por que essa abordagem foi escolhida e qual alternativa foi descartada. Isso permite que alguém a altere dentro de um ano sem ter que refazer a análise.
Existe um limite de tamanho por troco. Qualquer limite razoável funciona. Seu valor não reside no número em si, mas no fato de que ele força a divisão do trabalho em unidades compreensíveis.
Todas as três são baratas e nenhuma requer novas ferramentas. É a mesma lógica subjacente que sustenta os padrões de engenharia que aplicamos a cada entrega: contratos explícitos, ambientes isolados e documentação transferida para o cliente, porque O código e sua documentação são propriedade de quem os paga.
Em uma auditoria, há uma pergunta que guia o diagnóstico mais rapidamente do que qualquer métrica: Escolha um módulo aleatoriamente e peça a alguém da equipe para explicar por que ele foi feito dessa maneira..
Se uma explicação for fornecida e for coerente, o sistema será sustentável apesar de suas falhas. Se a resposta for que ele funciona e ninguém sabe exatamente por quê, o custo de cada alteração futura será maior do que qualquer estimativa indica, e essa diferença só aumentará.
Esse é o verdadeiro indicador de dívida técnica. Não são as linhas de código, nem a idade, nem a ferramenta usada para escrevê-lo: é a lacuna entre o que o sistema faz e o que a organização entende sobre ele.
É o custo adicional incorrido a cada alteração futura como consequência de decisões tomadas para agilizar o processo no momento. Não é medido pela idade do código ou por quem o escreveu, mas sim pelo custo de modificá-lo com segurança.
Não por causa de sua qualidade intrínseca, mas porque a restrição natural da escrita desaparece: as alterações aumentam de tamanho, as revisões tornam-se superficiais e a duplicação cresce. O GitClear documentou que os blocos duplicados aumentaram oito vezes em 2024.
Com uma regra simples: ninguém integra código que não consiga explicar em um quadro branco, respondendo qual problema ele resolve, por que foi resolvido daquela maneira e o que aconteceria se deixasse de existir. Não é necessário entender todos os detalhes da implementação.
Três: evidências escritas de uma pessoa expressando o que a empresa espera, documentação da decisão e da alternativa descartada, e um limite de tamanho por alteração que force o trabalho a ser dividido em unidades compreensíveis.
Porque copiar é a resposta usual quando você não entende o suficiente sobre o que já existe para reutilizá-lo. Cada cópia multiplica o número de lugares onde a mesma correção terá que ser aplicada no futuro.
Pedir a alguém da equipe que explique por que um módulo escolhido aleatoriamente foi construído daquela maneira. Se a explicação for coerente, o sistema é sustentável apesar de suas falhas; se a resposta for que ele funciona e ninguém sabe por quê, cada alteração custará mais do que o estimado.
Até que ponto sua equipe entende o sistema hoje? Realizamos auditorias de arquitetura, código, dívida técnica e segurança, e entregamos o diagnóstico por escrito em até 10 dias úteis, a um preço fixo. Solicitar auditoria →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
