Dívida técnica e refatoração com propósito

Descrever o custo que será herdado

Dívida técnica é uma condição que torna o trabalho futuro mais caro ou arriscado. O nome só ajuda quando conseguimos descrever a condição, o benefício presente e o custo esperado. Na Oficina Caracol, manter o registrador de reservas apenas em memória simplifica o laboratório e evita infraestrutura externa. A contrapartida é explícita: reiniciar o processo apaga as reservas e a memória de chaves. Essa escolha é compatível com uma simulação, mas precisaria ser revista antes de assumir compromisso persistente com pessoas reais.

Refatoração modifica a estrutura interna preservando o comportamento observável. A definição de referência enfatiza essa preservação [S17, definição de refatoração]. Os testes que já protegem os contratos podem fornecer a rede de segurança necessária. Testes de caracterização são especialmente úteis quando precisamos descobrir e registrar como um sistema existente se comporta; não são uma etapa adicional obrigatória em toda refatoração. Uma mudança de regra pública exige outra decisão e não deve ser escondida sob o rótulo de limpeza.

Registro de dívida preenchido

Refatorar com um contrato pequeno

Considere um exemplo isolado, separado dos arquivos do pacote: duas formas de produzir os títulos dos registros ativos. A entrada já foi validada segundo o contrato do catálogo. O comportamento a preservar inclui a ordem relativa e a ausência de alteração na entrada. Este exemplo não substitui listarAtivos, cuja saída pública possui os três campos documentados.

const titulosAntes = casos => {
  const resultado = [];
  for (const caso of casos) {
    if (caso.ativo) resultado.push(caso.titulo);
  }
  return resultado;
};

const titulosDepois = casos =>
  casos.filter(caso => caso.ativo).map(caso => caso.titulo);

Com os registros A ativo, B inativo e C ativo, ambas devem produzir os títulos de A e C, nessa ordem. O conjunto vazio deve produzir um array vazio. Essas são expectativas para conferir, não uma alegação de execução do código acima. Se o exemplo removesse a validação exigida por uma função pública, mudaria o contrato em vez de apenas reorganizar sua estrutura.

Procedimento de decisão e execução

• Registre o problema: duplicação específica, compreensão difícil ou custo mensurável. Associe a mudança a um benefício e a um responsável.
• Identifique os comportamentos a preservar e examine a proteção existente. Acrescente testes quando houver lacunas; use caracterização se o comportamento atual precisar ser conhecido.
• Separe a refatoração de novas funcionalidades e execute passos pequenos. Depois de cada passo relevante, verifique os contratos afetados.
• Compare o resultado com o objetivo. Uma estrutura diferente sem benefício reconhecível não demonstra que a dívida diminuiu.
• Atualize o registro com decisão, evidência e pendências. A responsabilidade permanece explícita mesmo quando a dívida é aceita temporariamente.

Erros e condição de avanço

O avanço exige comportamento preservado nas verificações pertinentes e benefício demonstrado no escopo da mudança. A dívida remanescente possui impacto, responsável, prioridade e decisão. A aprovação não depende de zerar toda dívida; depende de compreender a consequência e de não ocultar uma limitação impeditiva para o uso proposto.

Exercício e solução comentada

Dados: duas telas duplicam a formatação de um título. Corrigir a mesma regra demanda alterar dois lugares; a equipe estima quinze minutos extras por mudança e prevê quatro mudanças semelhantes. A proposta de extração custa quarenta minutos. Registre uma decisão sem tratar a estimativa como certeza.