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.