Refatorar: melhorar o código sem quebrar

Arrumar o quarto sem mudar de casa

Uma verdade libertadora sobre código limpo: ele quase nunca nasce limpo, ele fica limpo com o tempo. Na primeira escrita, o foco é fazer funcionar, e é natural que o código saia meio torto, com um nome ruim aqui, uma função grande demais ali, um trecho repetido acolá. Refatorar é o ato de voltar a esse código que já funciona e melhorar a sua estrutura interna, sem mudar o que ele faz por fora. A analogia perfeita é arrumar um quarto bagunçado: você não muda de casa nem joga nada fora que importe; você organiza o que já está lá para ficar mais fácil de usar. Depois de refatorar, o programa entrega exatamente o mesmo resultado que antes, para o usuário nada mudou, mas por dentro ficou mais legível, mais fácil de manter e menos propenso a bugs futuros. Refatorar é investir na saúde de longo prazo do código.

Os cheiros que pedem faxina

Como saber quando um código pede refatoração? Os programadores falam em cheiros de código: sinais na aparência que sugerem um problema de estrutura, mesmo sem ser um erro. Você já conhece todos eles, porque este módulo os apresentou. Nomes ruins que obrigam a investigar. Funções gigantes que fazem coisas demais. Código duplicado espalhado, violando o DRY. Aninhamento profundo, o código flecha que escorrega para o canto da tela. Comentários demais tentando explicar um trecho confuso. Cada um desses cheiros é um convite para refatorar aquele ponto: renomear para clarear, extrair uma função para encolher, centralizar a regra duplicada, aplicar cláusulas de guarda para achatar o aninhamento. Refatorar não é reescrever tudo; é fazer melhorias pontuais e cirúrgicas onde os cheiros aparecem, deixando o código um pouco melhor a cada passagem.

Refatorar com rede de segurança

Refatorar tem um risco embutido: ao mexer no código, você pode, sem querer, mudar o comportamento e introduzir um bug, justamente o oposto do objetivo. A proteção contra isso é a mesma que apareceu no módulo de robustez: os testes. Antes de refatorar, garanta que existe uma forma de verificar que o código faz o que deve, idealmente testes automatizados que conferem as saídas para entradas conhecidas. Com essa rede, você refatora com confiança: faz uma pequena melhoria, roda os testes, e se todos passam, sabe que o comportamento continua o mesmo. Se algum falha, você mudou algo que não devia e desfaz na hora, enquanto a mudança ainda é pequena e fácil de rastrear. A regra de ouro é refatorar em passos pequenos e verificados, nunca numa reescrita gigante e cega. Assim, a faxina melhora o código sem o risco de quebrá-lo, e essa é a diferença entre refatorar e simplesmente bagunçar de um jeito novo.

Com isso, você fecha o módulo de código limpo e, na prática, a parte de fundamentos do curso. Repare no que aconteceu: nomes, funções pequenas, DRY, comentários e refatoração não são regras isoladas, são um conjunto de hábitos que se reforçam e miram um único objetivo, deixar o código fácil de entender e de mudar. Esse objetivo importa porque programar de verdade é, na maior parte do tempo, mexer em código que já existe, seu ou de outra pessoa, e código limpo é o que torna esse trabalho possível sem sofrimento. Você agora tem as estruturas de dados, os algoritmos, a noção de eficiência, a robustez e a disciplina de código limpo. Só falta juntar tudo num projeto de verdade, e é exatamente isso que o último módulo propõe.