Toda vez que alteramos o código sem refatorá-lo, a podridão piora e se espalha. A podridão do código nos frustra, nos custa tempo e reduz indevidamente a vida útil de sistemas úteis. Em um contexto ágil, pode significar a diferença entre cumprir ou não um prazo de iteração.
A refatoração do código impiedosamente evita o apodrecimento, mantendo o código fácil de manter e estender. Essa extensibilidade é a razão para refatorar e é a medida de seu sucesso. Mas note que é apenas “safe” para refatorar o código extensivamente se tivermos conjuntos de testes de unidade extensos do tipo que obtemos se trabalharmos testando primeiro. Sem poder executar esses testes após cada pequeno passo em uma refatoração, corremos o risco de introduzir bugs. Se você estiver fazendo o verdadeiro desenvolvimento orientado a testes (TDD), no qual o design evolui continuamente, não terá escolha quanto à refatoração regular, pois é assim que o design evolui.
Higiene do código
Uma metáfora popular para refatoração é limpar a cozinha enquanto você cozinha. Em qualquer cozinha em que várias refeições complexas são preparadas por dia para mais de um punhado de pessoas, você normalmente descobrirá que a limpeza e a reorganização ocorrem continuamente. Alguém é responsável por manter a louça, as panelas, a própria cozinha, a comida, a geladeira tudo limpo e organizado de momento a momento. Sem isso, o cozimento contínuo logo entraria em colapso. Em sua própria casa, você pode ver efeitos não triviais ao adiar até mesmo pequenas quantidades de refatoração de pratos: você já tentou raspar a sujeira formada por Cocoa Crispies secos de uma tigela? Uma oportunidade perdida de dois segundos de enxágue pode se tornar dez minutos de raspagem agressiva.
“Refatorações” específicas
As refatorações são o oposto de mexer indefinidamente no código; eles são precisos e finitos. O definitivo de Martin Fowler livro sobre o assunto descreve 72 “refatorações” específicas pelo nome (por exemplo, “extract method”, que extrai um bloco de código de um método e cria um novo método para ele). Cada refatoração converte uma seção de código (um bloco, um método, uma classe) de um dos 22 estados “fedorentos” bem compreendidos para um estado mais ideal. Leva algum tempo para aprender a reconhecer as oportunidades de refatoração e implementá-las adequadamente.
Refatoração para padrões
A refatoração não ocorre apenas em níveis de código baixos. Em seu livro recente, Refatorando para padrões, Joshua Kerievsky argumenta habilmente que a refatoração é a técnica que devemos usar para introduzir padrões de design "gang of four" em nosso código. Ele argumenta que os padrões são frequentemente usados em excesso e muitas vezes introduzidos muito cedo nos sistemas. Ele segue o formato original de Fowler de mostrar e nomear “refatorações” específicas, receitas para levar seu código do ponto A ao ponto B. As refatorações de Kerievsky geralmente são de nível mais alto que as de Fowler e costumam usar as refatorações de Fowler como blocos de construção. Kerievsky também apresenta o conceito de refatoração “em direção” a um padrão, descrevendo quantos padrões de projeto têm várias implementações diferentes ou profundidades de implementação. Às vezes, você precisa de mais de um padrão do que em outras ocasiões, e este livro mostra exatamente como fazer parte do caminho até lá, ou todo o caminho até lá.
O fluxo de refatoração
Em um contexto de teste inicial, a refatoração tem o mesmo fluxo de qualquer outra alteração de código. Você tem seus testes automatizados. Você começa a refatoração fazendo a menor alteração discreta possível para compilar, executar e funcionar. Sempre que possível, você faz essas alterações adicionando ao código existente, em paralelo com ele. Você faz os testes. Em seguida, você faz a próxima pequena alteração discreta e executa os testes novamente. Quando a refatoração estiver em vigor e todos os testes forem executados corretamente, você voltará e removerá o antigo código paralelo malcheiroso. Depois que os testes forem executados limpos, você estará pronto.
Automação de refatoração em IDEs
A refatoração é muito, muito mais fácil de fazer automaticamente do que manualmente. Felizmente, cada vez mais ambientes de desenvolvimento integrado (IDEs) estão sendo construídos com suporte à refatoração automatizada. Por exemplo, um IDE popular para Java é eclipse, que inclui mais refatorações automáticas o tempo todo. Outro favorito é IntelliJ IDEA, que historicamente incluiu ainda mais refatorações. No mundo .NET, há pelo menos dois plug-ins de ferramenta de refatoração para o Visual Studio 2003, e somos informados de que as versões futuras do Visual Studio terão suporte integrado à refatoração.
Para refatorar o código no Eclipse ou no IDEA, selecione o código que deseja refatorar, abra a refatoração específica necessária em um menu e o IDE faz o resto do trabalho duro. Você é solicitado apropriadamente por caixas de diálogo para novos nomes para coisas que precisam de nomenclatura e para entradas semelhantes. Você pode reexecutar imediatamente seus testes para garantir que a alteração não quebrou nada. Se algo foi quebrado, você pode facilmente desfazer a refatoração e investigar.
