Refatoração em passos pequenos e verificados

Objetivo

Tornar o código existente mais legível e mais barato de alterar, demonstrando passo a passo que o seu comportamento observável permanece o mesmo.

Pré-requisitos

A definição de Fowler: um refactoring é uma alteração da estrutura interna do software que o torna mais fácil de entender e mais barato de modificar, sem mudar o seu comportamento observável. Isso pressupõe testes que registrem esse comportamento. Se não existirem, escreva primeiro testes de caracterização: chame o código com entradas representativas e fixe as saídas atuais como resultado esperado, mesmo que pareçam estranhas. Além disso, é preciso o catálogo em refactoring.com, com passos nomeados como Extract Function, Inline Function, Move Function, Rename Variable ou Introduce Parameter Object, e uma suíte de testes que execute em segundos.

Passos

1. Nomeie o estado desejado e o code smell que se quer eliminar (função longa, código duplicado, aglomerado de dados); anote a frase como rascunho da mensagem de commit.
2. Aplique um único refactoring nomeado, sempre que possível com a automação do editor, que faz renomeações e extrações em todos os pontos de chamada.
3. Execute os testes. Vermelho significa: desfazer o passo (undo do editor ou, se o último estado verde estiver commitado, git restore .), em vez de depurar para a frente; o passo foi grande demais ou o comportamento afinal não está coberto.
4. Faça commit após cada grupo razoável de passos verdes, com uma mensagem que comece por refactor: e não prometa nenhuma mudança de comportamento.
5. Coloque mudanças de comportamento estritamente em commits próprios, antes ou depois. Quem revisa precisa poder confiar que o diff de um refactoring é neutro quanto ao comportamento; assim, lê-o pela estrutura em vez de linha por linha.
6. Pare assim que o smell desaparecer. Generalização especulativa («com certeza vamos precisar disto») é um novo smell, não um refactoring.

Resultado esperado

Uma sequência de commits pequenos, todos verdes, cada um revisável em minutos, que juntos produzem a estrutura pretendida – e uma suíte de testes que ficou mais completa pelo caminho.

Limites e base de verificação

Os testes só protegem o que cobrem; tempo de execução, consumo de memória e concorrência podem mudar sem que se note. Reestruturações que atravessam fronteiras de módulos exigem a mesma disciplina, mais um plano, por exemplo o padrão Strangler Fig. A definição e o catálogo seguem as páginas citadas; a sequência de passos é uma sugestão sem medição.