Refatoração de Software

Propaganda
Refatoração de Software
THAINÁ MARIANI, 2016.
O que é?
 Atividade em que a estrutura interna de um software é modificada
de modo que seu comportamento externo seja preservado;
 O objetivo é melhorar a qualidade do software;
 Cada reestruturação realizada também é chamada de refatoração.
O que é?
 Atividade em que a estrutura interna de um software é modificada
de modo que seu comportamento externo seja preservado;
 O objetivo é melhorar a qualidade do software;
 Cada reestruturação realizada também é chamada de refatoração.
Refatoração Renomear Método
Em que artefatos pode ser aplicada?
 Código
•
•
•
•
•
•
•
Java
C++
C
C#
Python
PHP
AspectJ
Em que artefatos pode ser aplicada?
 Modelos
• Diagramas da UML
• Estruturais
• Comportamentais
• Refatoração em modelos é difícil pois às vezes o comportamento só
pode ser observado por meio dos diagramas comportamentais.
 Outros
• Requisitos;
• Banco da dados;
• HTML.
Quando é realizada?
 Regra de três;
 Antes de adicionar uma funcionalidade;
 Tempo necessário maior que o estimado;
 Encontrar e corrigir um bug;
 Revisão de código.
Quando é realizada?
 Métodos Ágeis;
 Desenvolvimento Orientado a Testes (TDD);
 Reengenharia;
 Fases
• Manutenção;
• Desenvolvimento;
• Projeto.
Quando não realizar?
 Código tão confuso que é mais fácil programar de novo;
 Código não funciona pois possui muitos bugs;
 Prazo final próximo.
Como pode melhorar o software?
 Reduz o número de bugs;
 Reduz o tamanho do código;
 Reduz o tempo para a entrega do software.
Como pode melhorar o software?
 Atributos de Qualidade
•
•
•
•
•
•
Entendimento
Manutenibilidade
Flexibilidade
Extensibilidade
Modularidade
Reusabilidade
• Princípios de Projeto
• Coesão
• Acoplamento
Como pode melhorar o software?
 Métricas podem ser utilizadas para medir atributos de qualidade e
propriedades de projeto.
Como pode melhorar o software?
 Exemplo: Quality Model for Object-Oriented Design (QMOOD)
Como pode melhorar o software?
 Reduz a quantidade de bad smells.
 Bad smells são decisões ruins de design.
•
•
•
•
•
•
Duplicated Code
Long Method
Comments
Lazy Class
God Class
Long Parameter List
God Class
Long Parameter List
user = userManager.create(USER_NAME, group, USER_NAME, "joshua", USER_NAME, LANGUAGE,
false, false, new Date(), "blah", new Date());
Como pode melhorar o software?
 Reduz a quantidade de anti-patterns;
 Anti-patterns são “soluções” inefetivas para um problema.
Diferem-se dos bad smells por serem:
• Processos, estruturas ou padrões;
• Existir outra solução documentada já conhecida como efetiva.
 Catálogo de anti-patterns:
•
http://c2.com/cgi/wiki?AntiPatternsCatalog
Como pode melhorar o software?
 Classificação dos anti-patterns:
• Negócio
• Organizacionais
• Gerência de Projeto
• Engenharia de Software
•
•
•
•
•
Projeto
Programação
Programação Orientada a Objetos
Metodologia
Gerência de Configuração
Como pode melhorar o software?
 Anti-patterns de Projeto
• Swiss army knife: Projetar uma interface muito complexa e
extremamente difícil de implementar;
• Stovepipe system: Sistema difícil de ser mantido devido aos
componentes mal relacionados.
Como pode melhorar o software?
Anti-patterns de Programação
•
•
•
•
•
•
•
Blind faith: Não checar a correção de um bug;
Boat anchor: Parte do sistema sem uso;
Lava flow: Código ruim colocado em constante mudança;
Gold Hammer: Tecnologia familiar aplicada em todos os problemas;
Cargo cult programming: Usar padrões sem saber o motivo;
Lasagna code: Código com muitas camadas desnecessárias;
Spaghetti code: Estruturas de código pouco compreensíveis.
Como pode melhorar o software?
 Anti-patterns de Programação Orientada a Objetos
• Yo-yo problem: Herança muito complexa;
• Poltergeists: Objetos em que o único propósito é passar informações
para outro objeto;
• Circular dependency: Dependências desnecessárias entre objetos.
Poltergeists
Circular dependency
Atividades
1) Identificar o artefato e os elementos que receberão a refatoração;
2) Determinar quais refatorações serão aplicadas e o que deverá ser
feito para garantir que o comportamento seja preservado;
3) Aplicar as refatorações;
4) Verificar o impacto nos atributos de qualidade;
5) Manter a consistência com os outros artefatos do software.
Suporte em IDEs
 Eclipse (Java, C++, PHP, Ruby)
• Plugin AutoRefactor para refatoração automática;
 Netbeans (Java, C++, PHP, Ruby, HTML, CSS);
 IntelliJ IDEA (Java);
 Visual Studio (C#).
Refatorações Documentadas
 Banco de Dados
S. W. Ambler, P. J. Sadalage, Refactoring Databases, 2007.
http://www.agiledata.org/essays/databaseRefactoringCatalog.html
 HTML
E. R. Harold, Refactoring HTML, 2008.
Refatorações Documentadas
 Modelos UML
G. Sunyé et al., Refactoring UML Models, 2001.
 Orientação a Objetos
C++: W. F. Opdyke, Refactoring Object-Oriented Frameworks, 1992.
Java: M. Fowler et al., Improving the Design of Existing Code, 2002
http://www.refactoring.com/catalog
Exemplos de Refatorações
ORIENTAÇÃO A OBJETOS
Renomear Método
 Funcionalidade:
• Muda o nome do método.
 Motivação:
• O nome do método não revela o seu propósito;
• O nome do método é muito confuso.
 Pode melhorar o entendimento e manutenibilidade do software.
 Pode ser aplicado em outros contextos, como por exemplo,
modelos.
 Outras variações: Renomear Classe, Renomear Atributo, etc.
Renomear Método
 Mecanismos:
I. Renomear o método;
II. Verificar se o método é implementado em uma subclasse ou
superclasse, caso sim, renomeá-las;
III. Mudar as chamadas do antigo método para o novo;
IV. Compilar e testar.
É importante para evitar...
 boolean returnTrue(){
return false;
}
 Xunxu()
 DoSomething()
 SomeMethod()
 OtherMethod()
 GetCustomerOrderDeliveryDetailsByCustomerIdAndDeliveryDateAndOrderStatus()
Extrair Método
 Funcionalidade:
• Extrai um fragmento de um método para um novo método.
 Motivação:
• Um método é muito longo;
• Um método necessita de muitos comentários para que seu propósito
seja entendido;
• Um método possui muitas funcionalidades diferentes.
Extrair Método
 Mecanismos:
I. Criar um novo método e nomeá-lo conforme seu propósito;
II. Extrair o código para o novo método;
III. Procurar variáveis utilizadas e ajustá-las como parâmetros ou
variáveis locais;
IV. Compilar;
V. Substituir o código extraído por uma chamada para o novo método;
VI. Compilar e testar.
Extrair Método
 Bad smells e anti-patterns que podem ser impactados:
•
•
•
•
Long Method;
God Class;
Comments;
Spaghetti Code.
Extrair Método
 Atributos de qualidade que podem ser impactados:
•
•
•
•
•
•
Entendimento;
Manutenibilidade;
Flexibilidade;
Extensibilidade;
Modularidade;
Reusabilidade.
Extrair Classe
 Funcionalidade:
• Cria uma nova classe e move métodos e atributos para ela.
 Motivação:
• Classe com muitas funcionalidades;
• Classe difícil de entender.
Extrair Classe
 Mecanismos:
I. Decidir como separar as responsabilidades da classe;
II. Criar uma nova classe;
III. Relacionar as duas classes;
IV. Mover todos os atributos necessários (Mover Atributo);
V. Compilar e testar após cada refatoração;
VI. Mover todos os métodos necessários (Mover Método);
VII. Compilar e testar após cada refatoração;
VIII. Revisar as interfaces das classes;
IX. Decidir o local (pacote, por exemplo) da nova classe;
Extrair Classe
 Bad smells e anti-patterns que podem ser impactados:
• God Class;
• Spaghetti Code.
Extrair Classe
 Atributos de qualidade que podem ser impactados:
•
•
•
•
•
Entendimento;
Manutenibilidade;
Extensibilidade;
Reusabilidade;
Modularidade.
Agrupar Classe
 Funcionalidade:
• Move todas as funcionalidades de uma classe para outra e a deleta.
 Motivação:
• Uma classe possui poucas responsabilidades.
Agrupar Classe
 Bad smells e anti-patterns que podem ser impactados:
•
•
•
•
•
Lazy Class;
Yo-yo problem;
Poltergeists;
Circular Dependency;
Duplicated Code.
Agrupar Classe
 Atributos de qualidade que podem ser impactados:
• Entendimento;
• Manutenibilidade;
• Flexibilidade.
Pull Up Método
 Funcionalidade:
• Move métodos que são idênticos de subclasses para a superclasse.
 Motivação:
• Remover código duplicado;
• Prevenir bugs quando apenas um método é alterado.
Pull Up Método
 Mecanismos:
I.
II.
III.
IV.
V.
VI.
Verificar se existem métodos duplicados;
Criar a o mesmo método na superclasse;
Compilar;
Excluir métodos das subclasses;
Compilar e testar;
Mudar as chamadas ao método.
Pull Up Método
 Bad smells e anti-patterns que podem ser impactados:
• Yo-yo problem;
• Duplicated Code.
Pull Up Método
 Atributos de qualidade que podem ser impactados:
• Entendimento;
• Manutenibilidade.
Push Down Método
 Funcionalidade:
• Move o método da superclasse para uma subclasse.
 Motivação:
• Um método de uma superclasse é relevante apenas para parte das
subclasses.
Push Down Método
 Mecanismos:
I.
II.
III.
IV.
V.
Declarar o método nas subclasses relevantes;
Remover o método da superclasse;
Compilar e testar;
Remover o método das subclasses que não precisam dele;
Compilar e testar.
Push Down Método
 Bad smells e anti-patterns que podem ser impactados:
• God class;
• Comments;
• Spaghetti Code.
Push Down Método
 Atributos de qualidade que podem ser impactados:
•
•
•
•
•
•
Entendimento;
Manutenibilidade;
Flexibilidade;
Extensibilidade;
Reusabilidade;
Modularidade.
Referências
M. Fowler, K. Beck, Refactoring: Improving the Design of Existing Code, Addison-Wesley, Boston, MA, USA,
1999.
T. Mens, T. Tourwe, A survey of software refactoring, IEEE Transactions on Software Engineering 30 (2)
(2004) 126–139.
W. F. Opdyke, Refactoring Object-oriented Frameworks, Ph.D. thesis, Champaign, IL, USA (1992).
E. Harold, Refactoring HTML: Improving the Design of Existing Web Applications, Addison-Wesley, 2008.
G. Sunyé, D. Pollet, Y. L. Traon, J.-M. Jézéquel, Refactoring UML Models, in: Proceedings of the International
Conference on The Unified Modeling Language, Modeling Languages, Concepts, and Tools, UML, 2001, pp.
134–148.
S. W. Ambler, P. J. Sadalage, Refactoring Databases: Evolutionary Database Design, Addison-Wesley, 2006.
William J. Brown, Hays W. McCormick, and Scott W. Thomas. 2000. Anti-Patterns Project Management (1st
ed.). John Wiley & Sons, Inc., New York, NY, USA.
Referências
William J. Brown, Hays W. “Skip” McCormick, III, and Scott H. Thomas. 1999. Antipatterns and Patterns in
Software Configuration Management. John Wiley & Sons, Inc., New York, NY, USA.
William H. Brown, Raphael C. Malveau, Hays W. "Skip" McCormick, and Thomas J. Mowbray. 1998.
Antipatterns: Refactoring Software, Architectures, and Projects in Crisis (1st ed.). John Wiley & Sons, Inc.,
New York, NY, USA.
Bill Dudney, Joseph Krozak, Kevin Wittkopf, Stephen Asbury, and David Osborne. 2002. J2EE Antipatterns (1
ed.). John Wiley & Sons, Inc., New York, NY, USA.
Catálogos de Anti-Patterns
http://c2.com/cgi/wiki?AntiPatternsCatalog
https://sourcemaking.com/antipatterns
Catálogos de Refatorações
http://www.agiledata.org/essays/databaseRefactoringCatalog.html
http://www.refactoring.com/catalog/
Exercício
Exercício
Exercício
Push Down Atributo
Atributos: cpf, aniversario
Classe de origem: Pessoa
Classe destino: Pessoa Fisica
Atributos: cnpj
Classe de origem: Pessoa
Classe destino: PessoaJuridica
Exercício
Pull Up Método
Método: mandarEmail()
Classe de origem: PessoaFisica e PessoaJuridica
Class destino: Pessoa
Renomer Método
Método: listDependents...
Classe: PessoaFisica
Exercício
Agrupar Classe
Classes: PessoaJuridicaDesativa e Pessoa Juridica
Extrair Método:
Método: ValidaCPFCNPJ()
Classe origem: Pessoa;
Classes destino: PessoaFisica e PessoaJuridica
Download