Cada vez que alteramos o código sem refatorá-lo, a deterioração piora e se espalha. A deterioração do código nos frustra, custa tempo e reduz indevidamente a vida útil de sistemas úteis. Em um contexto ágil, isso pode significar a diferença entre cumprir ou não o prazo de uma iteração.
Refatorar o código impiedosamente previne a deterioração, mantendo-o fácil de manter e estender. Essa extensibilidade é a razão para refatorar e a medida do seu sucesso. Mas observe que isso é apenas “safePara refatorar o código de forma tão extensa, é necessário ter conjuntos de testes unitários abrangentes, como os que obtemos ao trabalhar com a abordagem "test-first". Sem a capacidade de executar esses testes após cada pequena etapa de refatoração, corremos o risco de introduzir bugs. Se você pratica o verdadeiro desenvolvimento orientado a testes (TDD), no qual o design evolui continuamente, então não há outra opção senão realizar refatorações regulares, pois é assim que o design evolui.
Higiene de código
Uma metáfora popular para refatoração é a de limpar a cozinha enquanto se cozinha. Em qualquer cozinha onde várias refeições complexas são preparadas diariamente para mais de algumas pessoas, é comum encontrar a limpeza e a reorganização ocorrendo continuamente. Alguém é responsável por manter a louça, as panelas, a própria cozinha, os alimentos e a geladeira limpos e organizados a cada instante. Sem isso, o preparo contínuo de alimentos logo entraria em colapso. Em sua própria casa, você pode observar os efeitos significativos de adiar até mesmo pequenas tarefas de refatoração da louça: já tentou raspar a sujeira formada por flocos de chocolate secos de uma tigela? Dois segundos perdidos para enxaguar podem se transformar em dez minutos de raspagem agressiva.
Refatorações específicas
Refatorações são o oposto de ficar mexendo no código sem parar; elas são precisas e definitivas. A obra definitiva de Martin Fowler sobre o assunto é a derradeira refatoração. livro O texto descreve 72 "refatorações" específicas, nomeando-as (por exemplo, "extrair método", 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 "problemáticos" bem conhecidos para um estado mais otimizado. Leva tempo para aprender a reconhecer oportunidades de refatoração e a implementá-las corretamente.
Refatoração para padrões
A refatoração não ocorre apenas em níveis baixos do código. Em seu livro recente, Refatoração para PadrõesJoshua Kerievsky argumenta habilmente que a refatoração é a técnica que devemos usar para introduzir padrões de projeto do "grupo dos quatro" em nosso código. Ele defende que os padrões são frequentemente usados em excesso e introduzidos cedo demais nos sistemas. Kerievsky segue o formato original de Fowler, mostrando e nomeando "refatorações" específicas, receitas para levar seu código do ponto A ao ponto B. As refatorações de Kerievsky são geralmente de nível mais alto do que as de Fowler e frequentemente usam as refatorações de Fowler como blocos de construção. Kerievsky também introduz o conceito de refatoração "em direção a" um padrão, descrevendo como muitos padrões de projeto têm várias implementações diferentes, ou níveis de implementação. Às vezes, você precisa de um padrão mais do que em outras, e este livro mostra exatamente como chegar perto ou chegar completamente a esse ponto.
O fluxo de refatoração
Em um contexto de desenvolvimento orientado a testes (TDD), a refatoração segue o mesmo fluxo de qualquer outra alteração de código. Você tem seus testes automatizados. O processo de refatoração começa com a menor alteração discreta possível que compile, execute e funcione corretamente. Sempre que possível, essas alterações são feitas em paralelo com o código existente. Os testes são executados. Em seguida, a próxima pequena alteração discreta é feita e os testes são executados novamente. Quando a refatoração estiver concluída e todos os testes forem executados sem erros, o código paralelo antigo e problemático é removido. Assim que os testes forem executados sem erros, o processo está finalizado.
Automação de refatoração em IDEs
A refatoração é muito, muito mais fácil de automatizar do que fazer manualmente. Felizmente, cada vez mais ambientes de desenvolvimento integrados (IDEs) estão incorporando suporte à refatoração automatizada. Por exemplo, um IDE popular para Java é o Java. eclipse, que inclui cada vez mais refatorações automáticas. Outra favorita é IntelliJ IDEA, que historicamente incluiu ainda mais refatorações. No mundo .NET, existem pelo menos dois plugins de ferramentas de refatoração para o Visual Studio 2003, e fomos informados de que as versões futuras do Visual Studio terão suporte integrado para refatoração.
Para refatorar código no Eclipse ou no IntelliJ IDEA, você seleciona o código que deseja refatorar, escolhe a refatoração específica que precisa em um menu e a IDE faz o resto do trabalho pesado. Você será solicitado, por meio de caixas de diálogo, a dar novos nomes aos elementos que precisam ser nomeados e a inserir outras informações. Em seguida, você pode executar seus testes novamente imediatamente para garantir que a alteração não tenha quebrado nada. Se algo tiver sido quebrado, você pode desfazer a refatoração facilmente e investigar o problema.
