A dívida técnica não aparece do nada depois de um sprint ruim. Ela funciona mais como um imposto que você paga em cada funcionalidade futura. E quase sempre nasce das pequenas decisões que a gente toma no dia a dia: um atalho que parecia inofensivo, um nome de variável ruim, um teste que ficou para depois “só dessa vez”. A forma mais eficiente de reduzir dívida técnica não é um mega projeto de refatoração é mudar como você trata cada pull request.
Muita equipe encara o PR como o último passo antes do merge. O CI passou? Segue o jogo. Só que isso perde o ponto principal. O PR é a melhor ferramenta que você tem para impedir que a dívida entre no código. É onde o time cruza contexto, padrões e decisões.
O problema é que todo mundo está correndo. E aí pequenas coisas passam. A famosa frase “a gente arruma depois”. Você sabe como isso termina: esse “depois” vira um ticket esquecido e, meses mais tarde, vira a causa de uma falha em produção.
O papel de um tech lead não é virar gargalo revisando linha por linha. É criar um sistema no qual qualidade é o padrão. E esse sistema começa ajustando a forma como seu time faz PR.
O PR: sua melhor (e mais ignorada) ferramenta contra dívida técnica
Por que o processo de PR é tão importante?
Porque é a última vez que alguém olha para a mudança antes dela cair na main. É o momento em que intenção (“vou corrigir esse bug”) encontra implementação (“aqui está o código”). É ali que você garante que a solução não cria três novos problemas enquanto resolve um.
Tratar dívida técnica de forma reativa “sprint de refatoração”, “semana de limpeza” é um sinal claro de que o processo não está funcionando. Às vezes é inevitável, mas é caro e resolve só o sintoma. Quando você coloca o PR no centro, você controla a entrada. Você não está só pagando dívidas antigas, está evitando criar novas.
Definindo o padrão
O papel de um tech lead por exemplo não é revisar tudo sozinho. É definir o padrão que o time inteiro vai seguir. Você atua mais como editor do que como executor: orienta a direção, define o que é qualidade e garante que qualquer pessoa consiga aplicar esses critérios na revisão de um PR.
Para isso, “bom” não pode ser uma opinião. Precisa ser algo concreto, feedback subjetivo não ajuda.
“Não gostei disso” não diz o que precisa mudar. “Essa função passou do limite de complexidade que combinamos, vamos quebrar” diz.
Quando o time opera com critérios claros assim, a revisão deixa de depender do humor ou preferência de uma pessoa e passa a ser um processo previsível, repetível e compartilhado.
Algumas abordagens para reduzir dívida técnica em PRs
Vamos para a parte prática: como transformar essa visão em algo que funciona no dia a dia?
Crie diretrizes simples e claras para revisão
Coloque no CONTRIBUTING.md um guia curto explicando como revisar um PR. Nada longo. Só o essencial para ajudar qualquer pessoa do time a saber o que olhar.
- Corretude: Esse código faz o que deveria fazer? Resolve o problema descrito no ticket? Introduz algum bug ou edge case?
- Manutenibilidade e legibilidade: Um novo desenvolvedor vai entender esse código daqui a seis meses? Os nomes de variáveis são claros? A lógica é direta ou um prato de espaguete? Está consistente com os padrões existentes da base?
- Performance e segurança: Isso está introduzindo um N+1? Está lidando de forma segura com input de usuário? Estamos adicionando alguma dependência com vulnerabilidades conhecidas?
- Testes: Os testes realmente validam a nova lógica? Estão testando detalhes de implementação (frágeis) ou comportamento (robustos)? Há cobertura adequada para caminhos críticos?
Isso não é um checklist obrigatório para todo PR, mas um guia para quem for revisar. É só uma forma de evitar revisões vagas e dar ao time um “norte” comum.
Foque em refatoração incremental
A “regra do escoteiro” é sua melhor amiga: Sempre deixe o código melhor do que você encontrou.
Se um desenvolvedor está mexendo em uma parte especialmente bagunçada para corrigir um bug, dê autonomia para limpar a área imediata. Não precisa refatorar o módulo inteiro. Só renomear algumas variáveis confusas. Extrair uma condição complexa para uma função bem nomeada. Adicionar um teste que faltava.
Isso precisa ser incentivado de forma explícita. Se o time é cobrado só por story points, ninguém vai parar para fazer essas melhorias pequenas. É importante deixar claro que esses ajustes fazem parte do trabalho e têm impacto real no longo prazo. Quando alguém fizer, reconheça no chat da equipe. Mostrar que isso importa muda o comportamento do time.
Como fazer uma boa revisão (sem travar a sprint)
Um bom processo de revisão encontra equilíbrio entre qualidade e velocidade. O objetivo é melhorar o código, não ganhar discussão ou provar que você é mais esperto.
Crie um checklist mínimo viável no template do PR
Não transforme isso em burocracia. Algumas caixas simples no template de descrição do PR podem ajudar bastante.
Exemplo de template de PR:
Diferencie bloqueadores de sugestões
Isso é fundamental. Nem todo comentário tem o mesmo peso e o autor do PR precisa saber disso sem precisar adivinhar adivinhar. Use prefixos simples para deixar clara a intenção:
[Blocker] Algo que precisa ser ajustado antes do merge.
Exemplo: [Blocker]: Essa query nova está sem índice e pode travar a tabela.
[Suggestion] Algo que pode melhorar o código, mas não impede o merge.
Exemplo: [Suggestion]: Dá para usar map aqui no lugar de forEach. Fica a seu critério.
[Question] Quando você realmente não entendeu o motivo da mudança.
Exemplo: [Question]: Por que essa linha precisou ser alterada? Estou sem o contexto.
Essa convenção simples reduz atrito e ajuda a pessoa autora do PR a priorizar o que precisa de correção imediata e o que pode ser revisitado depois.
Anti-padrões comuns que criam dívida em revisões
Alguns comportamentos aparecem em quase todo time e, se você não cuida, viram dívida rapidamente:
O “LGTM” automático: Aprovar só porque o CI passou. É basicamente dizer que qualidade é opcional.
O mega PR: Um PR com milhares de linhas não vai ser revisado de verdade. As pessoas passam o olho, fazem um ou dois comentários e seguem. Incentive PRs menores e com escopo claro.
Discussões de estilo que não levam a nada: Brigar por nome de variável que não quebra nenhum padrão definido é perda de tempo. Isso é trabalho para linters e formatters, não para discussão humana.
O famoso “arruma depois”: É a frase que mais cria dívida técnica. Se algo está errado, corrija agora. Se é uma mudança maior, registre o problema, mas não deixe o PR piorar o estado atual da base.
No fim, tudo é cultura
Ferramentas ajudam. Processo ajuda. Mas só até certo ponto. Reduzir dívida técnica é, no fundo, um trabalho de cultura. É criar um ambiente onde as pessoas possam dizer quando um prazo está sacrificando qualidade, onde pequenas refatorações fazem parte do dia a dia, e onde feedback é visto como evolução do código, não como ataque pessoal.
Comece pequeno e depois ajuste e evolua.
