diff options
Diffstat (limited to 'usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt')
| -rw-r--r-- | usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt | 127 |
1 files changed, 0 insertions, 127 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 deleted file mode 100644 index a50a2e5..0000000 --- a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt +++ /dev/null @@ -1,127 +0,0 @@ -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. |