1 files changed, 0 insertions, 103 deletions
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.