Artigo Introdução de wulin.com (www.vevb.com): A palavra refatoração foi originalmente definida por Martin Fowler e Kent Beck. É uma modificação que facilita a compreensão da estrutura interna do software e facilita a alteração do software sem alterar o comportamento visível do software ... é uma maneira restrita de organizar o código e minimizar a chance de geração de bugs.
Às vezes, os programadores vêm até mim e dizem que não gostam do design de algo, e precisamos dar uma reconstrução abrangente para corrigir os erros. Oh oh. Isso não parece uma boa ideia. E isso não parece uma refatoração ...A palavra refatoração foi originalmente definida por Martin Fowler e Kent Beck. É uma modificação que facilita a compreensão da estrutura interna do software e facilita a alteração do software sem alterar o comportamento visível do software ... é uma maneira restrita de organizar o código e minimizar a chance de geração de bugs.
O resultado da reconstrução é que os métodos de atalho são referenciados, o código duplicado e morto são removidos, tornando o design e a lógica mais clara. É para usar as linguagens de programação melhor e mais inteligentes. É a vantagem de usar informações que você conhece agora, mas o desenvolvedor naquele momento não sabia - ou não as usou. Simplifique continuamente o código para facilitar a compreensão. Continuamente facilita e seguras suas mudanças futuras.
Durante esse processo, foram encontrados bugs e bugs foram modificados, o que não é uma reconstrução. A otimização não é uma reconstrução. O fortalecimento da captura de exceção e a adição de código preventivo não está refatorando. Tornar o código mais fácil de testar não é uma refatoração - embora a refatoração possa alcançar o mesmo efeito. Todas essas coisas são benéficas. Mas nenhum deles está refatorando.
Os programadores, especialmente aqueles que fazem trabalhos de manutenção, a limpeza do código é uma de suas tarefas diárias. Este é um trabalho básico e deve ser feito. A contribuição de Martin Fowler et al. é formatar os métodos de melhor prática de refatorar o código e arquivar os padrões de refatoração comuns e comprovados eficazes - os objetivos da refatoração e as etapas da refatoração - para a classificação do arquivo.
A refatoração é simples. Escrever testes antes de escrever o código o máximo possível pode impedir que você cometa erros. Ajustes estruturais de pequena escala, independentes e seguros no código e testam -os após cada ajuste para garantir que você não altere as características de comportamento do código - as funções são as mesmas de antes, mas o código parece diferente. O modo de refatoração e as ferramentas modernas de refatoração de IDE tornam a refatoração fácil, segura e barata.
Não refator
A refatoração pode ser considerada como uma medida que pode ajudar sua alteração no código. A refatoração do código deve ser feita antes de fazer alterações de código, o que possibilitará que você tenha certeza de que você entende o código e facilita e mais seguro introduzir alterações no código. Realize um teste de regressão em sua ação de refatoração. Em seguida, faça correções ou alterações. Teste novamente. Posteriormente, mais código pode ser refaturado para tornar seu código Alterar a intenção mais clara. Teste completo novamente. Reconstruir e mudar novamente. Ou mudar e depois refatorar.
Você não está refatorando para a refatoração, está refatorando porque deseja fazer outras coisas e a refatoração pode ajudá -lo a realizar essas coisas.
O escopo da refatoração deve ser determinado pelas alterações do código ou correções de código que você precisa implementar - o que você deve fazer para tornar as alterações do código mais seguras e concisas? Em outras palavras: não refatorie por causa da refatoração. Não refatore o código que você não pretende mudar ou não mudará.
REFACORAÇÃO SRACK para entender (refatoração de arranhões)
O livro de Michael Feather, "Trabalhando efetivamente com o Código Legado", menciona o conceito de refatoração de arranhões; Martin Fowler chama isso de refatoração para entender. Isso é usado para lidar com o código (ou não suportar) que você não entende, limpe -os para que você possa entender melhor o que eles fazem antes de modificá -lo e também ajudará você a depurar esses códigos. Depois de entender a verdadeira intenção de uma variável ou método, renomeá-los, dar a eles um nome mais apropriado, exclua o código que você não gosta de ler (ou achar inútil), desmontar declarações condicionais complexas e dividir programas longos em vários programas fáceis de entender.
Não se preocupe em revisar ou testar essas mudanças. Isso é para fazer com que sua reconstrução progrida rapidamente - isso permite esses códigos e como eles correm para produzir um protótipo rápido, mas incompleto, no seu cérebro. Aprenda com isso e jogue -os fora. Uma breve reconstrução também pode permitir que você experimente vários métodos de reconstrução e aprenda mais técnicas de reconstrução. Michael Feathers sugere que você deve prestar atenção às coisas que parecem inúteis ou particularmente úteis no processo, para que você possa fazer as coisas corretamente depois de concluir este exercício e realmente modificá -las - faça um pouco a pouco ao modificar, preste atenção ao método e modifique e teste.
O que é reconstrução em larga escala?
Reconstrução simples, mas óbvia do código: elimine a duplicação, modifique e altere as variáveis e os nomes de métodos para torná -lo mais significativo, refinar os métodos para facilitar o entendimento e a reutilização do código, simplificar a lógica condicional, substituir números sem sentido por variáveis nomeadas e reunir códigos semelhantes. Através desses refatores, você pode obter grandes recompensas em termos de compreensão e manutenção de código.
Comparados com essas reconstruções menores e em linha, as reconstruções de projeto mais significativas são significativamente diferentes deles - é isso que Martin Fowler se refere como grandes reconstruções. Mudanças grandes e caras vêm com muitos riscos técnicos. Este não é um código de limpeza e melhoria do design em seu processo de programação: é uma reformulação fundamental.
Algumas pessoas gostam de chamar o redesenhar ou reescrever ou reconstruir um sistema ou retrabalhar um sistema chamado reconstrução em larga escala. Como tecnicamente, eles não alteram as características funcionais da lógica de software - negócios, entrada e saída de software ainda são as mesmas de antes, mas a implementação do design e do código mudou. A diferença entre ele e a reconstrução convencional parece ser: um é reescrever um pedaço de código e o outro é reescrever um sistema. Enquanto você o fizer passo a passo, você pode chamá -lo de reconstrução - se estiver preso na substituição de um sistema antigo por um novo código por anos ou transformação em larga escala da arquitetura do sistema.
A refatoração em larga escala será horrível. Pode levar semanas, meses (ou até anos) para concluir e você precisa fazer alterações em muitas partes do software. O software não será executado como resultado, e essas alterações precisam ser lançadas várias vezes. Você precisa fazer andaimes temporários e soluções alternativas - especialmente quando você usa métodos de desenvolvimento ágil de curto ciclo. Neste momento, um método prático como o ramo por resumo é útil, o que pode ajudá -lo a gerenciar as alterações em seu código por um longo período de tempo.
E durante o desenvolvimento do novo código, você também deve manter o código antigo, o que torna a versão do código controlar muito problemática e inconveniente, tornando o código muito frágil e fácil de cometer erros - isso vai contra o objetivo pretendido da reconstrução. Às vezes, essa situação continua - esse processo de alternar código novo e antigo nunca pode ser concluído porque o melhor benefício é feito primeiro, ou porque o consultor que inicialmente trouxe a idéia fez outra coisa, ou o orçamento foi reduzido, e você odeia manter esse projeto de procrastinação.
Estes são refatorando-aqueles não são
É errado incorporar o conceito de reconstrução em esse desenvolvimento de projetos pesados. Eles são fundamentalmente outro tipo de trabalho, com custos e riscos de desenvolvimento completamente diferentes. Ele confunde a compreensão das pessoas sobre o que é a reconstrução e o que a reconstrução pode fazer.
A refatoração pode e deve ser integrada ao seu processo de escrita ou manutenção de seu código - como parte integrante do desenvolvimento diário/gerenciamento da qualidade, assim como os testes de gravação e as análises de código. A refatoração deve ser concluída em silêncio, continuamente e subestimadamente. Exige que dividamos nossa energia de trabalho nela e precisa levar em consideração sua existência em nossa avaliação da parada de construção e avaliação de riscos. Se feito corretamente, você não precisa explicar ou verificar esta parte do trabalho a pessoas de fora.
Tirar alguns minutos ou uma hora ou duas para refatorar é como uma modificação em seu processo de desenvolvimento e faz parte do trabalho. Se levar dias ou mais, não é uma refatoração; É uma reescrita, ou um reprovação. Se você precisar reservar explicitamente uma parte do tempo (ou todo o ciclo de sprint) para refatorar o código, se precisar solicitar a aprovação para limpar o código ou usar a limpeza do código como um requisito de desenvolvimento, não está refatorando - mesmo se usar as técnicas e ferramentas de refatoração, ainda estará fazendo outro tipo de trabalho.
Alguns programadores acreditam que é o direito e a obrigação de fazer modificações fundamentais e significativas para o código, e eles serão reprojetados e reescreverão em nome da refatoração, para que não decepcionem suas habilidades no futuro. Redesenhar e reescrever às vezes é a coisa certa a fazer. Mas por franqueza e clareza, não dê a essas atividades o nome da reconstrução.