Aula 7 - Boas práticas de Programação - Refatoração.pptx

Aula de Boas Práticas - Refatoração

1. Boas Práticas de Programação - Refatoração Conteúdo enriquecido com material gentilmente cedido pelo Prof. Marco Tulio Valente

2. Agenda Leis de Lehman; Refatoração; Definição; Catálogo de refatorações. Refatoração automatizada; Code (bad) smells; Débito técnico. 2

3. Leis de Lehman Leis empíricas sobre evolução de software; Propostas por Meir Lehman, IBM. O crescimento e a evolução de vários sistemas de grande porte foram examinados Objetivo : Definir uma teoria unificada para evolução de software; Resultados : Um conjunto de oito leis que “governam” a evolução de sistemas. 3

4. 1 - Mudança Contínua Sistemas devem ser continuamente adaptados ou eles se tornam progressivamente menos satisfatórios; O ambiente muda, novos requisitos surgem e o sistema deve ser modificado; Após o sistema modificado ser reimplantado, ele muda o ambiente. 4

5. 2 - Complexidade Crescente A medida que um sistema evolui, sua complexidade aumenta , a menos que seja realizado esforço para mantê-la ou diminuí-la; Manutenções preventivas são necessárias; 5

6. 3 - Auto-Regulação A evolução de software é um processo auto-regulável ; Uma grande alteração inibe futuras grandes alterações; 6

7. 4 - Estabilidade Organizacional Durante o ciclo de vida de um programa, sua taxa de desenvolvimento é quase constante; Independe de recursos dedicados ao desenvolvimento do sistema; Alocação de grandes equipes é improdutivo, pois o overhead de comunicação predomina. 7

8. 5 - Conservação de Familiaridade A taxa de evolução de um software está intimamente ligado ao grau de familiaridade dentre os profissionais que o mantém; Um grande incremento em uma release leva a muitos defeitos novos ; A release posterior será dedicada quase exclusivamente para corrigir os defeitos. 8

9. 6 - Crescimento Contínuo O conteúdo funcional de sistemas devem ser continuamente aumentado para manter a satisfação do usuário; A cada dia, o usuário fica mais descontente com o sistema; Novas funcionalidades são necessárias para manter a satisfação do usuário. 9

10. 7 - Qualidade Declinante A qualidade de sistemas parecerá estar declinando a menos que eles sejam mantidos e adaptados às modificações do ambiente; 10

11. 8 - Sistemas de Feedback Os processos de evolução incorporam sistemas de feedbacks ; Estes feedbacks devem ser considerados para conseguir melhorias significativas do produto. 11

12. Resumindo… Sistemas devem ser sempre mantidos para serem úteis; Mas manutenções aumentam a complexidade e deterioram a qualidade do código; A não ser que um trabalho seja realizado para evitar isso. 12

13. Resumindo… Sistemas devem ser sempre mantidos para serem úteis; Mas manutenções aumentam a complexidade e deterioram a qualidade do código; A não ser que um trabalho seja realizado para evitar isso. 13 Modernamente, este trabalho ganhou o nome de refatoração (refactoring) .

14. Refatoração Transformações de código que melhoram a manutenibilidade de um sistema mas sem afetar o seu funcionamento externo. 14

15. Refatoração Transformações de código que melhoram a manutenibilidade de um sistema mas sem afetar o seu funcionamento externo. 15 Dividir uma função em duas, renomear variável, mover função, extrair classe, etc.

16. Refatoração Transformações de código que melhoram a manutenibilidade de um sistema mas sem afetar o seu funcionamento externo. 16 Melhorar modularidade, projeto/arquitetura, testabilidade, código mais legível, etc.

17. Refatoração Transformações de código que melhoram a manutenibilidade de um sistema mas sem afetar o seu funcionamento externo . 17 Refatorações devem entregar o sistema funcionando exatamente como antes das transformações.

18. Refatoração 18

19. Refatoração 19 2018 2000 1999

20. Catálogo de Refatorações Extrações de métodos; Inline de métodos; Movimentação de métodos; Pull up method; Push down method. Extração de Classes; Renomeação. 20

21. Catálogo de Refatorações Extrações de métodos; Inline de métodos; Movimentação de métodos; Pull up method; Push down method. Extração de Classes; Renomeação. 21

22. Extração de Métodos Objetivo: extrair um trecho de código de um método f ( ) e levá-lo para um novo método g ( ) 22 Funcionalidade “B” é utilizada em diversos métodos diferentes = duplicação de código .

23. Extração de Métodos 23

24. Extração de Métodos 24 Antes

25. Extração de Métodos 25 Depois

26. Extração de Métodos 26 Danilo Silva, Nikolaos Tsantalis, Marco Tulio Valente. Why We Refactor? Confessions of GitHub Contributors. FSE 2016. https://dl.acm.org/doi/10.1145/2950290.2950305

27. Catálogo de Refatorações Extrações de métodos; Inline de métodos; Movimentação de métodos; Pull up method; Push down method. Extração de Classes; Renomeação. 27

28. Inline de métodos O contrário de extração; Para métodos muito pequenos que sejam chamados poucas vezes . Operação mais rara e menos importante do que a extração. 28

29. Inline de métodos 29 Antes

30. Inline de métodos 30 Antes Depois

31. Catálogo de Refatorações Extrações de métodos; Inline de métodos; Movimentação de métodos; Pull up method; Push down method. Extração de Classes; Renomeação. 31

32. Manutenção de métodos Não é raro encontrar um método implementado na classe errada; Apesar de implementado em uma classe A. um método f ( ) pode usar mais serviços de uma classe B. Deve-se, então, avaliar a possibilidade de mover f ( ) para a classe B. 32

33. Manutenção de métodos 33 Antes

34. Manutenção de métodos 34 Depois

35. Manutenção de métodos Quando isso ocorre em uma mesma hierarquia de classes, ganha nomes especiais. Pull up method -> mover um método de subclasses para uma superclasse; Push down method -> mover um método de uma superclasse para uma subclasse. 35

36. Pull up method 36

37. Push down method 37

38. Catálogo de Refatorações Extrações de métodos; Inline de métodos; Movimentação de métodos; Pull up method; Push down method. Extração de Classes; Renomeação. 38

39. Extração de Classes Recomendado quando um sistema possui uma classe A com muitas responsabilidades e atributos . Alguns desses atributos são relacionados e poderiam ter vida própria . Logo, podem ser extraídos para uma nova classe B. 39

40. Extração de Classes 40

41. Extração de Classes 41

42. Catálogo de Refatorações Extrações de métodos; Inline de métodos; Movimentação de métodos; Pull up method; Push down method. Extração de Classes; Renomeação. 42

43. Renomeação Renomear método, parâmetro, atributo, classe, etc. Nome dado ao elemento não foi uma boa escolha ; Responsabilidade do elemento mudou e o nome ficou desatualizado . 43

44. Renomeação Parte complexa não é renomear o elemento; Mas sim, atualizar os pontos de código em que ele é referenciado. 44

45. Renomeação Por exemplo, se um método f ( ) é renomeado para g ( ) , todas as chamadas de f ( ) devem ser atualizadas. Se f ( ) for muito usado, pode ser interessante extraí-lo para um novo método, com o novo nome, e manter o nome antigo, mas depreciado . 45

46. Renomeação 46

47. Renomeação Depreciação Mecanismo oferecidos por linguagens de programação para indicar um elemento de código desatualizado; Emite um warning e permite que a renomeação ocorra a baby steps ; 47

48. Refatoração automatizada 48

49. Refatoração automatizada 49

50. Refatoração automatizada 50 Danilo Silva, Nikolaos Tsantalis, Marco Tulio Valente. Why We Refactor? Confessions of GitHub Contributors. FSE 2016. https://dl.acm.org/doi/10.1145/2950290.2950305 Observação: O único rename analisado foi de pacote

51. Refatoração automatizada 51 Danilo Silva, Nikolaos Tsantalis, Marco Tulio Valente. Why We Refactor? Confessions of GitHub Contributors. FSE 2016. https://dl.acm.org/doi/10.1145/2950290.2950305

52. Code (ou Bad) Smells Indicadores de código de baixa qualidade; Difícil de manter, entender, modificar ou testar; Portanto, candidato a refatoração . 52

53. Code (ou Bad) Smells Exemplos Código duplicado; Feature Envy; Variáveis globais; Obsessão por tipos primitivos; 53

54. Code (ou Bad) Smells 54 Aiko Yamashita, Leon Moonen. Do developers care about code smells? An exploratory survey. WCRE 2013. https://ieeexplore.ieee.org/document/6671299

55. Código duplicado = clones 55 Código Original

56. Clone Tipo 1: Comentários e espaços 56 Código Original

57. Clone Tipo 2: Nomes diferentes 57 Código Original

58. Clone Tipo 3: Mudanças simples de comandos 58 Código Original

59. Clone Tipo 4: Algoritmo equivalente 59 Código Original

60. Feature Envy Método que “inveja” dados e métodos de outra classe; Usa mais métodos e dados dessa outra classe; Logo, é um candidato a ser movido para ela. 60

61. Feature Envy 61

62. Variáveis globais Acoplamento ruim; Dificulta o entendimento de um método; 62 Para entender o que f retorna, precisamos conhecer o valor de g

63. Obsessão por tipos primitivos CEP, data, hora, email, etc, não devem ser de tipos primitivos; Mas assim de um tipo próprio, com alguns métodos de validação de dados, por exemplo. Devemos analisar a possibilidade de criar classes que encapsulam valores e ofereçam operações para manipulá-los. 63

64. Antes de terminar… Débito Técnico Metáfora para explicar a importância de boas práticas e princípios de Engenharia de Software; Soluções não-ótimas de design que dificultam a manutenção e evolução de um sistema 64

65. Antes de terminar… Débito Técnico 65

66. Antes de terminar… Débito Técnico 66 Projeto no qual TD não foi pago Projeto no qual TD foi sendo pago Speed = velocidade de implementação de novas funcionalidades

67. Antes de terminar… Débito Técnico Ausência de testes; Problemas arquiteturais; Alto acoplamento; Code smells; Ausência completa de documentação; Código que não segue layout pré-definido. 67

68. Dúvidas? 68

69. Exercícios de fixação Marque V ou F: ( ) As Leis de Lehman são leis empíricas sobre manutenção e evolução de software. Uma delas afirma que manutenções tornam a estrutura interna de um sistema mais complexa e difícil de manter no futuro. ( ) Extração de métodos é um dos refactorings mais poderosos e com maior número de motivações. ( ) Inline de métodos é uma operação mais frequente do que sua operação oposta (extração de métodos). ( ) Pull Up Method e Push Down Method são casos particulares de movimentação de métodos, que ocorrem ao longo de uma hierarquia de herança. ( ) São exemplos de refactorings: extração de métodos, inline de métodos e melhoria do desempenho de um método. ( ) Débito técnico designa o possível déficit de conhecimento técnica de alguns membros de um time de desenvolvimento. 69

70. Exercícios de fixação Marque V ou F: ( V ) As Leis de Lehman são leis empíricas sobre manutenção e evolução de software. Uma delas afirma que manutenções tornam a estrutura interna de um sistema mais complexa e difícil de manter no futuro. ( V ) Extração de métodos é um dos refactorings mais poderosos e com maior número de motivações. ( F ) Inline de métodos é uma operação mais frequente do que sua operação oposta (extração de métodos). ( V ) Pull Up Method e Push Down Method são casos particulares de movimentação de métodos, que ocorrem ao longo de uma hierarquia de herança. ( F ) São exemplos de refactorings: extração de métodos, inline de métodos e melhoria do desempenho de um método . ( F ) Débito técnico designa o possível déficit de conhecimento técnico de alguns membros de um time de desenvolvimento. 70

71. Extraia o método g ( ) para a(s) linha(s) comentada(s) class A { void f() { int x = 10 ; x ++ ; print x; // extrair } } 71

72. Extraia o método g ( ) para a(s) linha(s) comentada(s) class A { void f() { int x = 10 ; x ++ ; print x; // extrair } } 72 class A { void g( int x) { print x; } void f() { int x = 10 ; x ++ ; g(x); } }

73. Extraia o método g ( ) para a(s) linha(s) comentada(s) class A { void f() { int x = 10 ; x ++ ; // extrair print x; // extrair int y = x + 1 ; ... } } 73

74. Extraia o método g ( ) para a(s) linha(s) comentada(s) class A { void f() { int x = 10 ; x ++ ; // extrair print x; // extrair int y = x + 1 ; ... } } 74 class A { int g( int x) { x ++ ; print x; return x; } void f() { int x = 10 ; x = g(x); int y = x + 1 ; ... } }