From 8a7dfa0972c83fd811a4296e7373574bea4a28d0 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 19 Jul 2020 20:34:40 +0700 Subject: [usth/ICT2.7] Remove Udacity transcribes --- .../20 - When Not To Refactor - lang_en_vs4.srt | 103 --------------------- 1 file changed, 103 deletions(-) delete mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt (limited to 'usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt') diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt deleted file mode 100644 index 53938de..0000000 --- a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt +++ /dev/null @@ -1,103 +0,0 @@ -1 -00:00:00,088 --> 00:00:02,860 -Now I want to conclude this discussion on refactoring by telling you - -2 -00:00:02,860 --> 00:00:07,190 -when you should not refactor. One first clear case is when - -3 -00:00:07,190 --> 00:00:10,410 -your code is broken. I want to make it very clear, refactoring - -4 -00:00:10,410 --> 00:00:13,450 -is not a way to fix your code in terms of its - -5 -00:00:13,450 --> 00:00:16,250 -functionality. It's a way to improve the design of your code. - -6 -00:00:16,250 --> 00:00:19,040 -So if your code does not compile or does not run - -7 -00:00:19,040 --> 00:00:21,780 -in a stable way, it's probably better to throw it away - -8 -00:00:21,780 --> 00:00:25,250 -and rewrite it rather then trying to refactor it. By definition refactoring - -9 -00:00:25,250 --> 00:00:26,780 -should maintain the functionality of the - -10 -00:00:26,780 --> 00:00:28,360 -system. It should be behavior preserving. - -11 -00:00:28,360 --> 00:00:31,100 -So if the code was broken before, it, it's probably going to be broken - -12 -00:00:31,100 --> 00:00:33,950 -afterwards as well. You may also want to avoid refactoring when a - -13 -00:00:33,950 --> 00:00:37,370 -deadline is close. Well, first of all, because refactoring might take a long - -14 -00:00:37,370 --> 00:00:41,360 -time and therefore might introduce risks of being late for the deadline. - -15 -00:00:41,360 --> 00:00:44,555 -And also, because of what we said before about introducing problems, you don't - -16 -00:00:44,555 --> 00:00:47,780 -want to introduce problems that might take you time to fix right before a - -17 -00:00:47,780 --> 00:00:50,660 -deadline. So if the deadline is too close, you might want to avoid - -18 -00:00:50,660 --> 00:00:54,310 -refactoring the code at that point. And finally, do not refactor if there - -19 -00:00:54,310 --> 00:00:58,430 -is no reason to. As we said before, you should refactor on demand. You - -20 -00:00:58,430 --> 00:01:00,960 -see a problem with the design of your code, with the structure of your - -21 -00:01:00,960 --> 00:01:03,790 -code, it's okay to refactor. If the code is fine, there is no reason - -22 -00:01:03,790 --> 00:01:06,470 -to refactor. I know that refactoring is fine, but you don't want to do - -23 -00:01:06,470 --> 00:01:09,280 -it all the time. The next thing I want to discuss, after discussing when - -24 -00:01:09,280 --> 00:01:12,970 -not to refactor, is when to refactor without an indication that will tell us - -25 -00:01:12,970 --> 00:01:15,820 -that it's time to refactor the code. And that leads us to the discussion - -26 -00:01:15,820 --> 00:01:17,280 -of a very interesting concept. -- cgit 1.4.1