A Refatoração Não é Uma Funcionalidade

A reescrita que nunca sai

O padrão é consistente. Uma equipa de engenharia, exausta por uma base de código frágil e uma montanha de atalhos acumulados, convence os fundadores de que o único caminho viável é o “reset total”. O desenvolvimento de funcionalidades para. A equipa começa a reescrever a aplicação do zero usando a framework que está na moda no Hacker News. Seis meses transformam-se em nove. Nove em doze. A equipa de vendas perde negócios porque não saiu nenhuma nova capacidade num ano. E quando a reescrita finalmente é lançada, faltam-lhe metade dos edge-cases obscuros que o sistema antigo tratava perfeitamente, lógica que nunca foi documentada porque ninguém a compreendia bem o suficiente para documentar.

Isto não é um cenário hipotético. É um dos modos de falha mais comuns em engenharia SaaS B2B. O erro fundamental não é técnico, é concetual. As equipas de produto interpretam fundamentalmente mal o que é a dívida técnica, como se acumula, e como deve ser paga.

A dívida técnica é um instrumento financeiro

O termo “dívida técnica” foi cunhado por Ward Cunningham como uma metáfora deliberada, e é brilhante. Tal como a dívida financeira, a dívida técnica não é inerentemente má. Contrair dívida permite avançar mais rápido. Se és uma startup a tentar encontrar product-market fit, deves contrair dívida técnica. Escreves código confuso para lançar uma funcionalidade em duas semanas em vez de dois meses, porque descobrir se os clientes realmente querem a funcionalidade é mais importante do que a pureza arquitetónica. É uma decisão racional e calculada, o equivalente em engenharia a contrair um empréstimo empresarial para aproveitar uma oportunidade de mercado.

O problema surge quando decides pagar apenas o valor mínimo do cartão de crédito. Se continuas a contrair dívida sem nunca amortizar o capital, os juros (sob a forma de bugs, ciclos de desenvolvimento lentos, suítes de testes instáveis e incidentes de produção) acabarão por consumir todo o orçamento de engenharia. Chegas a um ponto em que adicionar um simples botão demora três semanas porque a gestão de estado é uma teia confusa de dependências frágeis e não documentadas.

O blog de engenharia da Atlassian descreve isto como o “efeito areia movediça”. a cada sprint, a equipa entrega menos apesar de trabalhar as mesmas horas, porque uma percentagem crescente do esforço vai para lutar contra o código em vez de construir funcionalidades. Quando a velocidade cai abaixo de 40% da baseline histórica, a organização de produto cruzou um limiar crítico: os juros sobre a dívida já excedem o valor do trabalho novo.

Mas mesmo nesse limiar, a solução quase nunca é declarar falência arquitetónica e reescrever tudo. A solução é pagamento contínuo e incremental.

A Regra do Escuteiro como política de engenharia

A refatoração nunca deve aparecer como um ticket isolado no Jira com o título “Refatorar a camada de base de dados.” Quando se constroem aplicações web complexas, a refatoração não é uma funcionalidade; é uma disciplina contínua, tal como code review ou testes. Não se agenda um “sprint de testes.” Escrevem-se testes como parte de lançar funcionalidades.

A Regra do Escuteiro dita: “Deixa sempre o código que editaste um pouco melhor do que o encontraste.” Se um engenheiro tem a tarefa de adicionar um novo campo a um perfil de utilizador, deve também limpar a lógica de validação que toca pelo caminho. Renomear a variável ambígua. Extrair a função duplicada. Adicionar a anotação de tipo que falta. Nada disto são tarefas separadas, fazem parte da definição de “concluído” do ticket original.

Esta abordagem, a que o x078 aplica nos seus projetos de consultoria B2B (alinha automaticamente a qualidade de engenharia com o valor de negócio. Só amortizas dívida técnica nas áreas do código que estão ativamente a mudar. Se um pedaço de código horrível e legado está a funcionar perfeitamente em produção há cinco anos e ninguém precisa de o modificar) deixa-o estar. Não o refatores só porque é feio. O custo de refatorar código que ninguém toca é sempre mais alto do que o custo de o ignorar. A refatoração deve seguir o caminho da mudança, não o caminho da preferência estética.

# ❌ O anti-padrão da "Grande Reescrita"
# Sprint 1-12: Reescrita total do serviço de faturação
# Resultado: 12 meses, zero funcionalidades para o cliente, 50% dos edge-cases em falta

# ✅ A abordagem "Escuteiro"
# Sprint 1: Adicionar cálculo de IVA
#   → Também: extrair módulo tax_utils do monolítico billing.py
# Sprint 2: Adicionar suporte multi-moeda
#   → Também: substituir strings SQL por queries parametrizadas nas funções tocadas
# Sprint 3: Adicionar exportação de PDF de fatura
#   → Também: adicionar type annotations ao modelo Invoice, adicionar testes unitários

# Resultado: 3 funcionalidades entregues, 3 áreas do código melhoradas, zero perda de velocidade

Quantificar a dívida para decisores não-técnicos

A razão pela qual as equipas de engenharia lutam para conseguir orçamento para refatoração é que a enquadram como uma necessidade técnica (“limpar o código”) em vez de uma necessidade de negócio. Os executivos não querem saber de código limpo. Querem saber de risco e velocidade.

A mudança de comunicação exige traduzir problemas arquitetónicos em métricas de negócio. Em vez de dizer “O nosso ORM está desatualizado”, um líder de engenharia deve dizer: “Atualmente gastamos 25% da capacidade do sprint a escrever migrações SQL manualmente porque o nosso ORM não suporta as alterações de schema que o roadmap do produto exige. Atualizar o ORM vai recuperar 40 horas de engenharia por mês, permitindo-nos lançar a nova funcionalidade de faturação quatro semanas mais cedo.”

Ferramentas como o SonarQube conseguem quantificar dívida técnica em termos concretos, tempo de remediação estimado em horas, percentagem de duplicação de código, tendências de complexidade ciclomática. Quando consegues mostrar um gráfico que diz “o nosso backlog de remediação estimado cresceu de 200 para 800 horas nos últimos 12 meses”. a conversa com a liderança muda fundamentalmente. Já não estás a pedir permissão para limpar código. Estás a apresentar uma trajetória de risco e a propor uma estratégia de mitigação.

Quando a reescrita total é de facto justificada

Existem cenários estreitos onde uma reescrita completa (não refatoração iterativa) é a decisão correta. O handbook de SRE da Google documenta casos onde o paradigma fundamental do software é tão incompatível com os novos requisitos que alterações incrementais custariam mais do que recomeçar.

Cenários tipicamente justificados incluem: migrar uma aplicação single-tenant on-premise para uma arquitetura SaaS multi-tenant (as premissas de isolamento de base de dados mudaram permanentemente), converter uma API request-response síncrona para uma arquitetura event-driven quando o negócio mudou de cargas transacionais para streaming, ou substituir um runtime de linguagem proprietária que atingiu o fim de vida do fornecedor.

A distinção crítica: em cada um destes casos, é a arquitetura em si que é o problema, não a qualidade do código dentro dessa arquitetura. Se a arquitetura é sólida mas o código é confuso, refatora. Se a arquitetura é fundamentalmente incompatível com o futuro do negócio, reescreve, mas fá-lo como uma migração strangler fig (substituindo componentes gradualmente atrás de uma fachada), não um Big Bang.

Integrar a refatoração na definição de concluído

Para que isto seja sustentável, os líderes de engenharia devem parar de pedir permissão para refatorar. Em vez disso, incluam o custo da refatoração em cada estimativa. Se uma funcionalidade demora três dias a construir e dois dias a limpar a dívida técnica envolvente, a estimativa para essa funcionalidade é cinco dias. Não três dias para a funcionalidade mais um ticket separado de dois dias de refatoração que será inevitavelmente desvalorizado.

Quando a refatoração é enquadrada como um extra opcional, as organizações de produto vão sempre optar por saltá-la a favor de velocidade de curto prazo. Quando é enquadrada como parte não-negociável do “concluído”. a saúde do produto a longo prazo é protegida automaticamente. O objetivo não é ter um código imaculado. O objetivo é ter um código que permita à equipa entregar valor de forma segura e previsível durante a próxima década, sem nunca precisar de parar o mundo para uma reescrita.

No terreno, em conjunto com a experiência acumulada na Webxtek Studio, aplicamos exatamente estes padrões operacionais em setores exigentes como fabrico têxtil técnico b2b e produção de cerâmicas avançadas e técnicas. Quando alinhas a tua estrutura através de web apps e websites de alta performance, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.