about summary refs log tree commit diff
path: root/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt
blob: 800ffb55be268c71633d48015223fda8bd4c234a (plain) (blame)
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,100 --> 00:00:02,469
A couple of minutes ago we talked about the fact that well, we

2
00:00:02,469 --> 00:00:05,260
might need to change our design a lot, so how we going to do

3
00:00:05,260 --> 00:00:08,540
that, that's going to be expensive. Well it's not very expensive, if we can

4
00:00:08,540 --> 00:00:10,876
do efficient refactoring. Which is another

5
00:00:10,876 --> 00:00:13,120
one of the important xp practices. And

6
00:00:13,120 --> 00:00:15,280
what does it mean to refactor? It means to take a piece of

7
00:00:15,280 --> 00:00:19,530
code who's design might be suboptimal, because for example, we evolved it, we

8
00:00:19,530 --> 00:00:22,600
didn't take into account that from the beginning some of the features that

9
00:00:22,600 --> 00:00:25,110
had to be added later, probably because we didn't even know about this

10
00:00:25,110 --> 00:00:28,200
feature, because the requirements evolved. So we're going to take this piece

11
00:00:28,200 --> 00:00:31,870
of code and we're going to restructure it, so that it becomes simple

12
00:00:31,870 --> 00:00:34,070
and maintainable. Developers are expected to

13
00:00:34,070 --> 00:00:35,590
refactor as soon as opportunities for

14
00:00:35,590 --> 00:00:39,530
improvement, are found. And that happens for example, before adding some code.

15
00:00:39,530 --> 00:00:41,730
You might look at the code that you're about to modify, or

16
00:00:41,730 --> 00:00:43,850
to which you are about to add parts, and say can we

17
00:00:43,850 --> 00:00:47,060
change the program to make the addition simple, that has maintainability or

18
00:00:47,060 --> 00:00:50,220
we can do it after adding some code to our code base.

19
00:00:50,220 --> 00:00:52,730
We might look at the code, the resulting code, and say well

20
00:00:52,730 --> 00:00:55,770
can we make the program simpler? Was the running all the tests

21
00:00:55,770 --> 00:00:57,920
and the key point here is that we don't want to refactor on

22
00:00:57,920 --> 00:01:01,580
speculation, but we want to refactor on demand, on the system, and the

23
00:01:01,580 --> 00:01:04,840
process needed. Again the goal is just to keep the code simple

24
00:01:04,840 --> 00:01:07,680
and maintainable, not to over do it. And as I mentioned before

25
00:01:07,680 --> 00:01:10,810
we're going to have a whole lesson, the next lesson on refactoring. So

26
00:01:10,810 --> 00:01:13,470
we're going to go in more depth in the discussion of this topic.