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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
1
00:00:00,150 --> 00:00:02,520
Now that we saw a number of refactorings, we also saw
2
00:00:02,520 --> 00:00:05,950
how refactorings can be performed automatically within an ID, I'd like
3
00:00:05,950 --> 00:00:09,230
to make you aware of some risks involved with the user
4
00:00:09,230 --> 00:00:12,510
refactorings. Refactorings are a very powerful tool, but you also have to
5
00:00:12,510 --> 00:00:15,820
be careful, first of all when you do more complex refactorings,
6
00:00:15,820 --> 00:00:18,540
you may also introduce subtle faults. What, we don't really call
7
00:00:18,540 --> 00:00:21,040
regression errors. You might change something in the class. You might
8
00:00:21,040 --> 00:00:23,140
think that that's a behavior preserving
9
00:00:23,140 --> 00:00:25,200
transformation when considering the whole code,
10
00:00:25,200 --> 00:00:27,860
and instead your change is affecting the behavior of some of the
11
00:00:27,860 --> 00:00:30,980
other parts of the code. So, it's introducing a regression that will cause
12
00:00:30,980 --> 00:00:32,670
some other functionality, some other piece
13
00:00:32,670 --> 00:00:34,320
of functionality some other feature, to
14
00:00:34,320 --> 00:00:37,190
work incorrectly. So you always have to be careful, and as we saw
15
00:00:37,190 --> 00:00:39,750
at the beginning one way to avoid that is to run tests.
16
00:00:39,750 --> 00:00:43,080
Every time you make a refactoring every time you change your code and
17
00:00:43,080 --> 00:00:46,280
refactor your code. So is to get the least some confidence in
18
00:00:46,280 --> 00:00:47,540
the fact that your refactoring is
19
00:00:47,540 --> 00:00:50,290
indeed behavior preserving. Also consider the refactoring
20
00:00:50,290 --> 00:00:54,680
should not. Be abused. Refactoring should be performed when it's needed. It's
21
00:00:54,680 --> 00:00:57,570
useful to improve the design of your code when you see problems
22
00:00:57,570 --> 00:00:59,680
with the design of the code. Shouldn't just be applied for the
23
00:00:59,680 --> 00:01:02,720
final code because you can apply, for example, easily within a tool.
24
00:01:02,720 --> 00:01:06,030
So be careful not over doing it when you refactor. And for
25
00:01:06,030 --> 00:01:08,310
the same reason that we mentioned at the beginning, you should be
26
00:01:08,310 --> 00:01:10,600
particularly careful when you're using refactoring
27
00:01:10,600 --> 00:01:12,290
for systems that are in production.
28
00:01:12,290 --> 00:01:15,260
Because if you introduce a problem, before the system goes in production,
29
00:01:15,260 --> 00:01:16,750
then you might be able to catch it earlier,
30
00:01:16,750 --> 00:01:19,780
with testing. Or before it's released. But, if you introduce
31
00:01:19,780 --> 00:01:21,750
a problem for a system in production, then you have
32
00:01:21,750 --> 00:01:24,440
to issue a new version of the code. You'll be
33
00:01:24,440 --> 00:01:26,860
affecting, you might be affecting some users, because the code
34
00:01:26,860 --> 00:01:29,050
fails on their machine. So, you have to be twice
35
00:01:29,050 --> 00:01:31,190
as careful, when you are doing refactoring, when you're changing
36
00:01:31,190 --> 00:01:33,010
your code for a system that is already in production.
|
