From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- .../2 - Introduction - lang_en_vs4.srt | 127 +++++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt (limited to 'usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt') 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. -- cgit 1.4.1