1 files changed, 127 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt
new file mode 100644
index 0000000..a50a2e5
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt
@@ -0,0 +1,127 @@
+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.