1) O documento discute o conceito de refactoring e como ele pode melhorar a manutenção de software removendo complexidade e deterioração do código. 2) Refactoring envolve transformações no código que melhoram a manutenibilidade sem alterar o funcionamento externo do sistema. Isso inclui extração de métodos, movimentação de métodos e extração de classes. 3) Code smells como código duplicado e variáveis globais são bons indicadores de código que pode ser melhorado com refactoring.

1. 1
Engenharia de Software e Sistemas
Cap. 9 - Refactoring
Prof. Dr. Thiago Mendes e Prof. Dr. Cleber Lira
thiagosouto@ifba.edu.br, cleberlira@ifba.edu.br
1
Licença CC-BY; créditos para Marco Tulio Valente. Engenharia de Software Moderna: Princípios e Práticas para Desenvolvimento de Software com
Produtividade, 2020 https://engsoftmoderna.info, @engsoftmoderna.

2. Relembrando Cap. 1 (Introdução)
2

3. Manutenção de Software
● Preventiva: bugs "latentes"
● Corretiva: bugs reportados por usuários
● Adaptativa: customizações, novas versões de LP/SO
● Evolutiva: novas funcionalidades
● Refactoring: melhorias no código ou design
3

4. Antes de começar com refactoring …
Leis de Lehman
4

5. Leis de Lehman
● Leis empíricas sobre evolução de software
● Propostas por Meir Lehman, nas décadas 70-80
5

6. Resumo das Leis de Lehman
● 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
6
Modernamente, este trabalho ganhou
o nome de refactoring

7. Refactoring
● Transformações de código que melhoram a
manutenibilidade de um sistema mas sem afetar o seu
funcionamento externo
7

8. Refactoring
● Conceito tornou-se bastante popular ...
8
2018
2000
1999

9. Refactoring
● Refactoring = refatoração
● Não vamos traduzir… termo em inglês é muito usado
9

10. Eunão sou um excelente programador, mas um bom
programador com excelentes hábitos – Kent Beck
10

11. Catálogo de Refactorings
● Extração de Métodos
● Inline de Métodos
● Movimentação de Métodos
● Extração de Classes
● Renomeação
● etc
11

12. Extração de Métodos
12

13. Extração de Métodos
13

14. Um exemplo real ...
14

15. 15
Antes

16. 16
Depois

17. 17
Danilo Silva, Nikolaos Tsantalis, Marco Tulio Valente. Why
We Refactor? Confessions of GitHub Contributors. FSE
2016.
Canivete-suíço dos
refactorings

18. Inline de Métodos (contrário de extração)
18

19. 19
Antes

20. 20
Depois

21. Movimentação de Métodos
21

22. 22

23. Casos particulares de movimentação
(ao longo de uma hierarquia de classes)
23

24. 24
Pull Up Method

25. 25
Push Down Method

26. Extração de Classes
26

27. 27

28. Renomeação
(variáveis, parâmetros, métodos, classes, exceções, etc)
28

29. Dar bons nomes a variáveis é um dos
problemas mais difíceis em programação!
29

30. 30
Renomação é o refactoring mais popular
Murphy-Hill, et al. How We Refactor, and How We Know It. IEEE TSE 2012.

31. Prática de Refactorings
31

32. Refactorings dependem de testes
Desenvolvedores evitam refatorações em sistemas
sem testes. Em vez disso, eles reduzem as modificações
àquelas necessárias para implementar novas
funcionalidades ou corrigir bugs. Assim, a complexidade
vai se acumulando e erros de projeto não são corrigidos
-- John Ousterhout
32

33. Quando refatorar?
1. Refactorings oportunistas
2. Refactorings planejados
33

34. Refactorings Oportunistas
● Realizados no meio de uma outra tarefa de programação
● Tipo de refactoring mais comum
● Para cada mudança que tiver que realizar em um
sistema, primeiro torne-a fácil (aviso: isso pode ser difícil),
então realize a mudança facilmente -- Kent Beck
34

35. Refactorings Planejados
● Correção de um problema de design mais complexo
● Sessão apenas para realização de refactorings
35

36. Refactorings Automatizados
(realizados com auxílio de uma IDE)
36

37. 37

38. 38

39. 39
Danilo Silva, Nikolaos Tsantalis, Marco Tulio Valente. Why We Refactor?
Confessions of GitHub Contributors. FSE 2016.
Observação: O único rename
analisado foi de pacote

40. 40

41. Code Smells
41

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

43. Catálogo de Code Smells
● Código Duplicado
● Métodos Longos
● Classes Grandes
● Feature Envy
● Métodos com Muitos
Parâmetros
● Variáveis Globais
43
● Obsessão por Tipos
Primitivos
● Objetos Mutáveis
● Classes de Dados
● Comentários

44. Código Duplicado
44

45. Código Duplicado
● Dificulta a manutenção
● Portanto, código candidato a refatoração
45

46. 46
Aiko Yamashita, Leon Moonen. Do
developers care about code smells? An
exploratory survey. WCRE 2013.

47. Código Duplicado ⇒ Clones
47

48. Clone Tipo 1 (comentários e espaços)
48
Código Original

49. Clone Tipo 2 (tipo 1 + nomes diferentes)
49
Código Original

50. Clone Tipo 3 (tipo 2 + mudanças em comandos)
50
Código Original

51. Clone Tipo 4 (algoritmos diferentes, mas equivalentes)
51
Código Original

52. Feature Envy
52

53. 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
53

54. 54

55. Variáveis Globais
55

56. Variáveis Globais
● Acoplamento ruim
● Dificulta o entendimento de um método
56
Para entender o que f retorna, precisamos conhecer o valor de g
Esse valor pode variar entre chamadas de f, etc

57. Obsessão por Tipos Primitivos
57

58. Obsessão por Tipos Primitivos
● CEP, Moeda, Data, Hora, Cor, Email, etc não devem ser
de tipos primitivos
● Mas sim de um tipo próprio, com alguns métodos
● Por exemplo, métodos para validação de valores
58

59. Objetos Mutáveis
59

60. Objetos Mutáveis vs Imutáveis
● Mutáveis: estado pode mudar
● Imutáveis: uma vez criados, estado não muda
60

61. Objetos Imutáveis: Strings em Java
61
Hello World
HELLO WORLD

62. Por que objetos imutáveis são "bons"?
● Dão "segurança" a quem criou o objeto
● Pode-se passar o objeto para outros métodos e ter
certeza de que eles não vão alterar o seu estado
62

63. Como interpretar esse code smell
● Sempre que possível, implemente objetos imutáveis
● Principalmente, objetos mais simples (CEP, Data, Hora, etc)
● Mas, por outro lado, em linguagens imperativas é natural
ter um bom número de objetos mutáveis.
63

64. Comentários
64

65. A ideia é a seguinte:
"não comente código ruim, reescreva-o"
-- B. Kerninghan & P. J. Plauger
65

66. 66

67. 67

68. Comentários "Ruído" (nada acrescentam …)
68
// this function sends an email
void sendEmail() {
...
}
// this class holds data for an employee
public class Employee {
...
}

69. Mais um exemplo de comentários "ruído"
69
Comentários apenas repetem o
que já está bem claro no código
Fonte: A Philosophy of Software Design (capítulo 13)

70. Evidentemente, nem todo comentário é um
code smell ...
70

71. Quando é útil comentar?
● Código complexo por natureza
71
// format matched kk:mm:ss EEE, MMM dd, yyy
Pattern timePattern = Pattern.compile("d*:d*:d* w*, w*, d*, d*");

72. Quando é útil comentar?
72
● Documentação de APIs
/**
* Registers the text to display in a tool tip. The text
* displays when the cursor lingers over the component.
*
* @param text the string to display. If the text is null,
* the tool tip is turned off for this component.
*/
public void setToolTipText(String text) {

73. Antes de terminar...
Débito Técnico
73

74. Débito Técnico
● Metáfora para explicar a importância de boas práticas e
princípios de Engenharia de Software
● Proposto por Ward Cunningham (1992)
● Soluções não-ótimas de design que dificultam a
manutenção e evolução de um sistema
74

75. 75

76. 76
Projeto no qual TD
não foi pago
Projeto no qual TD foi
sendo pago
Speed = velocidade de implementação de novas funcionalidades

77. Exemplos de Débito Técnico
● Ausência de testes
● Ausência de builds automatizado
● Problemas arquiteturais
● Alto acoplamento e baixa coesão
● Code smells
● Ausência completa de documentação
● Código que não segue layout pré-definido
77

78. Fim
78