Refatoração de código

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

Em programação de computadores e projeto de software , refatoração de código é o processo de reestruturação do código de computador existente — alterando a fatoração — sem alterar seu comportamento externo. A refatoração visa melhorar o design, estrutura e/ou implementação do software (seus atributos não funcionais ), preservando sua funcionalidade . As vantagens potenciais da refatoração podem incluir melhor legibilidade do código e complexidade reduzida ; estes podem melhorar a manutenibilidade do código fontee criar uma arquitetura interna ou modelo de objeto mais simples, limpo ou expressivo para melhorar a extensibilidade . Outro objetivo potencial para refatoração é o desempenho aprimorado; engenheiros de software enfrentam um desafio contínuo para escrever programas que funcionem mais rápido ou usem menos memória.

Normalmente, a refatoração aplica uma série de microrrefatorações básicas padronizadas , cada uma das quais é (geralmente) uma pequena alteração no código-fonte de um programa de computador que preserva o comportamento do software ou pelo menos não modifica sua conformidade com os requisitos funcionais. Muitos ambientes de desenvolvimento fornecem suporte automatizado para executar os aspectos mecânicos dessas refatorações básicas. Se bem feita, a refatoração de código pode ajudar os desenvolvedores de software a descobrir e corrigir bugs ou vulnerabilidades ocultos ou inativosno sistema simplificando a lógica subjacente e eliminando níveis desnecessários de complexidade. Se feito mal, pode falhar no requisito de que a funcionalidade externa não seja alterada e, assim, introduzir novos bugs.

Ao melhorar continuamente o design do código, tornamos mais fácil e fácil trabalhar com ele. Isso está em nítido contraste com o que normalmente acontece: pouca refatoração e muita atenção para adicionar novos recursos de forma conveniente. Se você adquirir o hábito higiênico de refatorar continuamente, descobrirá que é mais fácil estender e manter o código.

—  Joshua Kerievsky, Refatorando para Padrões [1]

Motivação

A refatoração geralmente é motivada pela percepção de um cheiro de código . [2] Por exemplo, o método em questão pode ser muito longo ou pode ser quase uma duplicata de outro método próximo. Uma vez reconhecidos, esses problemas podem ser resolvidos refatorando o código-fonte ou transformando-o em uma nova forma que se comporta da mesma forma que antes, mas que não "cheira mais".

Para uma rotina longa, uma ou mais sub-rotinas menores podem ser extraídas; ou para rotinas duplicadas, a duplicação pode ser removida e substituída por uma função compartilhada. A falha em realizar a refatoração pode resultar no acúmulo de dívida técnica ; por outro lado, a refatoração é um dos principais meios de pagamento da dívida técnica. [3]

Benefícios

Existem duas categorias gerais de benefícios para a atividade de refatoração.

  1. Manutenibilidade . É mais fácil corrigir bugs porque o código-fonte é fácil de ler e a intenção de seu autor é fácil de entender. [4] Isso pode ser alcançado reduzindo grandes rotinas monolíticas em um conjunto de métodos individualmente concisos, bem nomeados e de propósito único. Isso pode ser alcançado movendo um método para uma classe mais apropriada ou removendo comentários enganosos.
  2. Extensibilidade . É mais fácil estender os recursos do aplicativo se ele usar padrões de design reconhecíveis e fornecer alguma flexibilidade onde antes não existia. [1]

A engenharia de desempenho pode remover ineficiências em programas, conhecidas como inchaço de software, decorrentes de estratégias tradicionais de desenvolvimento de software que visam minimizar o tempo de desenvolvimento de um aplicativo em vez do tempo necessário para sua execução. A engenharia de desempenho também pode adaptar o software ao hardware no qual ele é executado, por exemplo, para tirar proveito de processadores paralelos e unidades vetoriais. [5]

Desafios

A refatoração requer a extração da estrutura do sistema de software, modelos de dados e dependências entre aplicativos para recuperar o conhecimento de um sistema de software existente. [6] A rotatividade de equipes implica em falta ou conhecimento impreciso do estado atual de um sistema e sobre as decisões de projeto feitas por desenvolvedores que estão saindo. Outras atividades de refatoração de código podem exigir esforço adicional para recuperar esse conhecimento. [7] As atividades de refatoração geram modificações arquiteturais que deterioram a arquitetura estrutural de um sistema de software. Tal deterioração afeta propriedades arquitetônicas, como manutenibilidade e compreensibilidade, que podem levar a um redesenvolvimento completo de sistemas de software. [8]

As atividades de refatoração de código são protegidas com inteligência de software ao usar ferramentas e técnicas que fornecem dados sobre algoritmos e sequências de execução de código. [9] Fornecer um formato compreensível para o estado interno da estrutura do sistema de software, modelos de dados e dependências entre componentes é um elemento crítico para formar um entendimento de alto nível e, em seguida, visões refinadas do que precisa ser modificado e como. [10]

Testando

Testes de unidade automáticos devem ser configurados antes da refatoração para garantir que as rotinas ainda se comportem conforme o esperado. [11] Testes unitários podem trazer estabilidade até mesmo para refatorações grandes quando executados com um único commit atômico . Uma estratégia comum para permitir refatorações seguras e atômicas abrangendo vários projetos é armazenar todos os projetos em um único repositório , conhecido como monorepo . [12]

Com o teste de unidade em vigor, a refatoração é então um ciclo iterativo de fazer uma pequena transformação de programa , testá-la para garantir a correção e fazer outra pequena transformação. Se a qualquer momento um teste falhar, a última pequena alteração é desfeita e repetida de uma maneira diferente. Através de muitos pequenos passos, o programa se move de onde estava para onde você quer que esteja. Para que esse processo muito iterativo seja prático, os testes devem ser executados muito rapidamente, ou o programador teria que gastar uma grande fração de seu tempo aguardando a conclusão dos testes. Os defensores da programação extrema e outros desenvolvimentos ágeis de software descrevem essa atividade como parte integrante do ciclo de desenvolvimento de software .

Técnicas

Aqui estão alguns exemplos de micro-refactorings; alguns deles podem se aplicar apenas a determinados idiomas ou tipos de idioma. Uma lista mais longa pode ser encontrada no livro de refatoração de Martin Fowler [2] [ página necessária ] e no site. [13] Muitos ambientes de desenvolvimento fornecem suporte automatizado para essas micro-refatorações. Por exemplo, um programador pode clicar no nome de uma variável e selecionar a refatoração "Encapsulate field" em um menu de contexto . O IDE solicitaria detalhes adicionais, normalmente com padrões sensatos e uma visualização das alterações de código. Após a confirmação pelo programador, ele realizaria as alterações necessárias em todo o código.

  • Técnicas que permitem maior compreensão
  • Técnicas que permitem mais abstração
    • Encapsular campo – forçar o código para acessar o campo com métodos getter e setter
    • Generalize type – crie tipos mais gerais para permitir mais compartilhamento de código
    • Substitua o código de verificação de tipo por estado/estratégia [16]
    • Substitua condicional por polimorfismo [17]
  • Técnicas para quebrar o código em partes mais lógicas
    • A Componentização divide o código em unidades semânticas reutilizáveis ​​que apresentam interfaces claras, bem definidas e simples de usar.
    • A classe Extract move parte do código de uma classe existente para uma nova classe.
    • Extrair método, para transformar parte de um método maior em um novo método. Ao quebrar o código em partes menores, é mais fácil de entender. Isso também se aplica a funções .
  • Técnicas para melhorar nomes e localização de código
    • Mover método ou mover campo – mover para uma classe ou arquivo de origem mais apropriado
    • Renomear método ou renomear campo – alterando o nome para um novo que revele melhor sua finalidade
    • Pull up – na programação orientada a objetos (OOP), mova para uma superclasse
    • Empurre para baixo – em OOP, mova para uma subclasse [13]
  • Detecção automática de clones [18]

Refatoração de hardware

Embora o termo refatoração originalmente se referisse exclusivamente à refatoração de código de software, nos últimos anos o código escrito em linguagens de descrição de hardware também foi refatorado. O termo refatoração de hardware é usado como um termo abreviado para refatoração de código em linguagens de descrição de hardware. Como as linguagens de descrição de hardware não são consideradas linguagens de programação pela maioria dos engenheiros de hardware, [19] a refatoração de hardware deve ser considerada um campo separado da refatoração de código tradicional.

A refatoração automatizada de descrições de hardware analógico (em VHDL-AMS ) foi proposta por Zeng e Huss. [20] Em sua abordagem, a refatoração preserva o comportamento simulado de um projeto de hardware. A medida não funcional que melhora é que o código refatorado pode ser processado por ferramentas de síntese padrão, enquanto o código original não pode. A refatoração de linguagens de descrição de hardware digital, embora a refatoração manual, também foi investigada pelo colega da Synopsys , Mike Keating. [21] [22] Seu objetivo é tornar sistemas complexos mais fáceis de entender, o que aumenta a produtividade dos projetistas.

História

O primeiro uso conhecido do termo "refactoring" na literatura publicada foi em um artigo de setembro de 1990 por William Opdyke e Ralph Johnson . [23] Ph.D. de Griswold. tese, [24] Ph.D. de Opdyke. tese, [25] publicada em 1992, também usou este termo. [26] Embora a refatoração de código tenha sido feita informalmente por décadas, o Ph.D. de William Griswold em 1991. A dissertação [24] é um dos primeiros grandes trabalhos acadêmicos sobre refatoração de programas funcionais e procedurais, seguido pela dissertação de 1992 de William Opdyke [25] sobre a refatoração de programas orientados a objetos, [26]embora toda a teoria e maquinaria estejam disponíveis há muito tempo como sistemas de transformação de programas . Todos esses recursos fornecem um catálogo de métodos comuns para refatoração; um método de refatoração tem uma descrição de como aplicar o método e indicadores para quando você deve (ou não) aplicar o método.

O livro de Martin Fowler Refactoring: Improving the Design of Existing Code é a referência canônica. [ segundo quem? ]

Os termos "factoring" e "factoring out" têm sido usados ​​desta forma na comunidade Forth desde pelo menos o início dos anos 1980. O Capítulo Seis do livro de Leo Brodie , Thinking Forth (1984) [27] é dedicado ao assunto.

Em programação extrema, a técnica de refatoração Extract Method tem essencialmente o mesmo significado que fatoração em Forth; para quebrar uma "palavra" (ou função ) em funções menores e de manutenção mais fácil.

Refatorações também podem ser reconstruídas [28] posthoc para produzir descrições concisas de mudanças complexas de software registradas em repositórios de software como CVS ou SVN.

Refatoração de código automatizada

Muitos editores de software e IDEs têm suporte à refatoração automatizada. É possível refatorar o código do aplicativo, bem como o código de teste. [29] Aqui está uma lista de alguns desses editores, ou os chamados navegadores de refatoração .

Veja também

Referências

  1. ^ a b Kerievsky, Joshua (2004). Refatorando para Padrões . Addison Wesley.
  2. ^ a b Fowler, Martin (1999). Reestruturação. Melhorando o design do código existente . Addison-Wesley. pág.  63ss . ISBN 978-0-201-48567-7.
  3. ^ Suryanarayana, Girish (novembro de 2014). Refatoração para cheiros de design de software . Morgan Kaufmann. pág. 258. ISBN 978-0128013977.
  4. ^ Martin, Robert (2009). Código limpo . Prentice Hall.
  5. ^ Leiserson, Charles E.; Thompson, Neil C.; Emer, Joel S.; Kuszmaul, Bradley C.; Lampson, Butler W.; Sanches, Daniel; Schardl, Tao B. (2020). "Há muito espaço no topo: o que impulsionará o desempenho do computador após a lei de Moore?" . Ciência . 368 (6495): eaam9744. doi : 10.1126/science.aam9744 . PMID 32499413 . 
  6. ^ Haendler, Thorsten; Neumann, Gustavo (2019). "Um Framework para a Avaliação e Treinamento de Competências de Refatoração de Software" . Proc. Da 11ª Conferência Internacional sobre Gestão do Conhecimento e Sistemas de Informação (KMIS). : 307-316. doi : 10.5220/0008350803070316 . ISBN  978-989-758-382-7. S2CID  204754665 .
  7. ^ Nassif, Matthieu; Robillard, Martin P. (novembro de 2017). "Revisitando a perda de conhecimento induzida pela rotatividade em projetos de software". 2017 IEEE International Conference on Software Maintenance and Evolution (ICSME) : 261–272. doi : 10.1109/ICSME.2017.64 . ISBN  978-1-5386-0992-7. S2CID  13147063 .
  8. ^ van Gurp, Jilles; Bosch, janeiro (março de 2002). "Erosão do projeto: problemas e causas". Jornal de Sistemas e Software . 61 (2): 105–119. doi : 10.1016/S0164-1212(01)00152-2 .
  9. ^ Hassan, Ahmed E.; Xie, Tao (novembro de 2010). "Inteligência de software: o futuro dos dados de engenharia de software de mineração". In Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research (FoSER '10) : 161–166. doi : 10.1145/1882362.1882397 . S2CID 3485526 .  
  10. ^ Novais, Renato; Santos, José Amâncio; Mendonça, Manoel (2017). "Avaliando experimentalmente a combinação de várias estratégias de visualização para análise de evolução de software". Jornal de Sistemas e Software . 128 : 56-71. doi : 10.1016/j.jss.2017.03.006 .
  11. ^ Fowler, Martin (1999). Refatoração: melhorando o design do código existente . Reading, MA: Addison-Wesley. ISBN 978-0201485677. OCLC  41017370 .
  12. ^ Inteligente, John Ferguson (2008). Java Power Tools . "O'Reilly Media, Inc.". pág. 301. ISBN 9781491954546. Recuperado em 26 de julho de 2018 .
  13. ^ a b (estes são apenas sobre OOP no entanto). Técnicas de refatoração no site de refatoração de Fowler
  14. ^ Ferrante, Jeanne; Ottenstein, Karl J.; Warren, Joe D. (julho de 1987). "O gráfico de dependência do programa e seu uso na otimização". Transações ACM em Linguagens e Sistemas de Programação . ACM. 9 (3): 319–349. doi : 10.1145/24039.24041 . S2CID 505075 .  
  15. ^ Donglin, Linag; Harrold, MJ (novembro de 2008). "Cortar objetos usando gráficos de dependência do sistema". Processos. Conferência Internacional de Manutenção de Software . IEEE: 319-349. doi : 10.1109/ICSM.1998.738527 . ISBN  978-0-8186-8779-2. S2CID  18160599 .
  16. ^ "Substituir código de verificação de tipo com Estado/Estratégia" .
  17. ^ "Substituir condicional por polimorfismo" .
  18. ^ Bruntink, Magiel, et al. " Uma avaliação das técnicas de detecção de clones para preocupações transversais ." Manutenção de Software, 2004. Anais. 20ª Conferência Internacional do IEEE sobre. IEEE, 2004.
  19. ^ Linguagens de descrição de hardware#HDL e linguagens de programação
  20. ^ Kaiping Zeng, Sorin A. Huss, "refinamentos de arquitetura por refatoração de código de modelos comportamentais VHDL-AMS". ISCAS 2006
  21. ^ M. Keating: "Complexidade, abstração e os desafios de projetar sistemas complexos", no tutorial DAC'08 [1] Arquivado em 28/03/2016 no Wayback Machine "Bridging a Verification Gap: C++ to RTL for Practical Design"
  22. ^ M. Keating, P. Bricaud: Reuse Methodology Manual for System-on-a-Chip Designs , Kluwer Academic Publishers, 1999.
  23. ^ Opdyke, William F. ; Johnson, Ralph E. (setembro de 1990). "Refactoring: Uma Ajuda no Projeto de Estruturas de Aplicativos e Evolução de Sistemas Orientados a Objetos". Anais do Simpósio de Programação Orientada a Objetos com Ênfase em Aplicações Práticas (SOOPPA) . ACM.
  24. ^ a b Griswold, William G (julho de 1991). Reestruturação de Programas como Auxílio à Manutenção de Software (PDF) (Tese de Doutorado). Universidade de Washington . Recuperado em 24/12/2011 .
  25. ^ a b Opdyke, William F (junho de 1992). Refatorando Frameworks Orientados a Objetos (tese de doutorado). Universidade de Illinois em Urbana-Champaign. Arquivado a partir do original (Postscript compactado) em 16/12/2019 . Recuperado em 2008-02-12 .
  26. ^ a b "Martin Fowler, "MF Bliki: EtymologyOfRefactoring"" .
  27. ^ Brodie, Leo (2004). Pensando Adiante . págs. 171-196. ISBN 0-9764587-0-5. Arquivado a partir do original em 16 de dezembro de 2005 . Recuperado em 3 de maio de 2020 .
  28. ^ Sokolov, Andriy. "O que é refatoração de código?" .
  29. ^ Xuan, Jifeng; Cornu, Benoit; Martinez, Matias; Baudry, Benoit; Seinturier, Lionel; Monperrus, Martin (2016). "B-Refactoring: Refatoração automática de código de teste para melhorar a análise dinâmica" . Tecnologia da Informação e Software . 76 : 65-80. doi : 10.1016/j.infsof.2016.04.016 .
  30. ^ "O que há de novo no Xcode 9" .
  31. ^ "Refactoring no Qt Creator" .

Leitura adicional

Links externos