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.