Melhorando um algoritmo que funciona (sem quebrar nada)

Funcionar é o começo, não o fim

Código se escreve uma vez e se lê dezenas: pelo colega que vai dar manutenção, pelo você de daqui a seis meses (que é praticamente um estranho) e por quem precisar caçar um bug com as técnicas deste módulo. Por isso, entre dois algoritmos que produzem exatamente a mesma saída, o mais claro vale mais. Refatorar é investir nessa clareza: mexer na forma preservando o comportamento. Não é reescrever do zero, não é adicionar recurso novo, não é corrigir bug. É pegar o que funciona e deixá-lo mais fácil de entender, com a mão firme de quem sabe provar que nada mudou.

As três melhorias com melhor retorno você já conhece de módulos anteriores, agora reunidas num ritual só. Nomes que se explicam, do módulo 3: a variável “x” vira “precoTotal” e metade dos comentários fica desnecessária. Repetição extraída, do módulo 12: o mesmo bloco copiado três vezes vira uma função chamada três vezes, e a próxima correção acontece num lugar só. E bordas tratadas, da aula 3 deste módulo: a decisão de guarda entra antes da conta perigosa. Nenhuma das três muda a saída para as entradas comuns; todas mudam a vida de quem lê.

A prova de que nada mudou

Melhorar sem medir é como apertar parafuso de olhos fechados: pode estar tudo bem, pode estar caindo a asa. A medição do refatorador é o teste de mesa comparado. Antes de mexer, execute o algoritmo original com duas ou três entradas (uma comum e uma de borda) e anote as saídas: essa é a fotografia do comportamento. Depois de mexer, execute a versão nova com as MESMAS entradas. Saídas idênticas: melhoria aprovada. Qualquer diferença: você não refatorou, você mudou o comportamento, e agora precisa decidir se foi de propósito ou se acabou de fabricar uma regressão.

// Antes: soma escrita duas vezes, nomes mudos
t <- 0
para i de 1 até 3 faça
  t <- t + i
fim
escreva(t)

// Depois: nome claro, mesma lógica
total <- 0
para numero de 1 até 3 faça
  total <- total + numero
fim
escreva(total)
// as duas versões escrevem 6: comportamento preservado

Refatoração honesta: o leitor ganhou clareza, a saída não mudou um milímetro.

total <- 0
para numero de 1 até 4 faça
  total <- total + numero
fim
escreva(total)

Inclua sempre uma entrada de borda no par de fotografias. É comum a refatoração preservar o caminho feliz e alterar a fronteira sem ninguém notar: o laço que antes rodava de 1 até N e agora roda de 0 até N produz a mesma soma em vários casos e uma soma diferente quando os valores mudam de natureza. A borda é onde as versões divergem primeiro; fotografe-a antes e depois, e as regressões silenciosas perdem o esconderijo.

Quando parar de melhorar

Refatoração é ferramenta, não hobby infinito. O critério de parada é prático: o algoritmo está claro o bastante para um colega entender sem você do lado? As bordas prováveis estão tratadas? A repetição óbvia foi extraída? Então pare e siga para o próximo problema. Existe até um lembrete clássico entre programadores: o ótimo é inimigo do entregue. Polir um algoritmo pela décima vez rende menos que aplicar o módulo 13 inteiro no próximo: testar na mesa, rastrear, blindar as bordas e depurar com método é um ciclo que melhora a cada repetição, e o módulo 14 traz problemas do mundo real para você rodá-lo por inteiro.