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
|
1
00:00:00,088 --> 00:00:02,860
Now I want to conclude this discussion on refactoring by telling you
2
00:00:02,860 --> 00:00:07,190
when you should not refactor. One first clear case is when
3
00:00:07,190 --> 00:00:10,410
your code is broken. I want to make it very clear, refactoring
4
00:00:10,410 --> 00:00:13,450
is not a way to fix your code in terms of its
5
00:00:13,450 --> 00:00:16,250
functionality. It's a way to improve the design of your code.
6
00:00:16,250 --> 00:00:19,040
So if your code does not compile or does not run
7
00:00:19,040 --> 00:00:21,780
in a stable way, it's probably better to throw it away
8
00:00:21,780 --> 00:00:25,250
and rewrite it rather then trying to refactor it. By definition refactoring
9
00:00:25,250 --> 00:00:26,780
should maintain the functionality of the
10
00:00:26,780 --> 00:00:28,360
system. It should be behavior preserving.
11
00:00:28,360 --> 00:00:31,100
So if the code was broken before, it, it's probably going to be broken
12
00:00:31,100 --> 00:00:33,950
afterwards as well. You may also want to avoid refactoring when a
13
00:00:33,950 --> 00:00:37,370
deadline is close. Well, first of all, because refactoring might take a long
14
00:00:37,370 --> 00:00:41,360
time and therefore might introduce risks of being late for the deadline.
15
00:00:41,360 --> 00:00:44,555
And also, because of what we said before about introducing problems, you don't
16
00:00:44,555 --> 00:00:47,780
want to introduce problems that might take you time to fix right before a
17
00:00:47,780 --> 00:00:50,660
deadline. So if the deadline is too close, you might want to avoid
18
00:00:50,660 --> 00:00:54,310
refactoring the code at that point. And finally, do not refactor if there
19
00:00:54,310 --> 00:00:58,430
is no reason to. As we said before, you should refactor on demand. You
20
00:00:58,430 --> 00:01:00,960
see a problem with the design of your code, with the structure of your
21
00:01:00,960 --> 00:01:03,790
code, it's okay to refactor. If the code is fine, there is no reason
22
00:01:03,790 --> 00:01:06,470
to refactor. I know that refactoring is fine, but you don't want to do
23
00:01:06,470 --> 00:01:09,280
it all the time. The next thing I want to discuss, after discussing when
24
00:01:09,280 --> 00:01:12,970
not to refactor, is when to refactor without an indication that will tell us
25
00:01:12,970 --> 00:01:15,820
that it's time to refactor the code. And that leads us to the discussion
26
00:01:15,820 --> 00:01:17,280
of a very interesting concept.
|
