1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
1
00:00:00,090 --> 00:00:02,790
Let me start this lesson by discussing what is refactoring.
2
00:00:02,790 --> 00:00:06,590
Refactoring is the process of applying transformation or refactoring to a
3
00:00:06,590 --> 00:00:09,320
program. So as to obtain a refactor program. With an
4
00:00:09,320 --> 00:00:12,850
improved design but with same functionality as the original program. So
5
00:00:12,850 --> 00:00:15,520
key aspect of refactoring is the fact that refactoring should
6
00:00:15,520 --> 00:00:18,150
be somatic to perserving So what is the main goal of
7
00:00:18,150 --> 00:00:22,030
refactoring? The goal is to keep the program readable, understandable, and
8
00:00:22,030 --> 00:00:25,260
maintainable as we evolve it. And to do this by eliminating
9
00:00:25,260 --> 00:00:28,530
small problems soon, so that you can avoid big trouble later. And
10
00:00:28,530 --> 00:00:31,750
I want to stress once more a key feature of refactoring, which
11
00:00:31,750 --> 00:00:34,790
is the fact that it is behavior per serving. But how can
12
00:00:34,790 --> 00:00:38,130
we ensure that the refactoring is behavior per serving? In other words,
13
00:00:38,130 --> 00:00:40,980
how can we ensure that the program does the same thing before
14
00:00:40,980 --> 00:00:43,560
and after applying a refactoring. So what we would like to do
15
00:00:43,560 --> 00:00:47,160
is to have some guarantee that, that happens. And unfortunately in general,
16
00:00:47,160 --> 00:00:50,360
there are no guarantees. But something we can do is to test
17
00:00:50,360 --> 00:00:53,690
the code. For example, we can write tests that exercise the
18
00:00:53,690 --> 00:00:56,390
parts of the program affected by the refactoring, and if we're in
19
00:00:56,390 --> 00:00:59,430
a [INAUDIBLE] context, we might already have plenty of test cases
20
00:00:59,430 --> 00:01:01,914
that exercise that part of the code. So we might just have
21
00:01:01,914 --> 00:01:04,780
to rerun the test cases after the refactoring. And in fact,
22
00:01:04,780 --> 00:01:07,930
that's a very advantageous situation, and that's a very good use of
23
00:01:07,930 --> 00:01:10,970
existing test cases. And I want to make sure that you remember,
24
00:01:10,970 --> 00:01:15,500
and that you beware that tests provide no guarantees. Testing can only
25
00:01:15,500 --> 00:01:18,990
show the presence of defects, but cannot demonstrate their absence.
26
00:01:18,990 --> 00:01:21,090
So we can use testing to get confidence in our
27
00:01:21,090 --> 00:01:23,990
refactorings, but we can't really guarantee that the refactorings are
28
00:01:23,990 --> 00:01:26,820
behavior preserving. I'd also like to point out that for some
29
00:01:26,820 --> 00:01:30,100
simple refactoring, we can use a static analysis to actually
30
00:01:30,100 --> 00:01:33,160
provide these guarantees. And in fact we will see examples of
31
00:01:33,160 --> 00:01:37,050
such refactorings that are incorporated into IDs and that leverage
32
00:01:37,050 --> 00:01:40,070
these kinds of analysis to perform refactoring in a safe way.
|
