1 files changed, 103 insertions, 0 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
new file mode 100644
index 0000000..53938de
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt
@@ -0,0 +1,103 @@
+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.