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 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 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;
...
}
}