1 files changed, 131 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt
new file mode 100644
index 0000000..1da50e6
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt
@@ -0,0 +1,131 @@
+1
+00:00:00,230 --> 00:00:02,000
+We saw at the beginning of the lesson, what are the
+
+2
+00:00:02,000 --> 00:00:05,490
+goals of refactoring? Or what are the reasons ,why we need to
+
+3
+00:00:05,490 --> 00:00:09,130
+refactor in the first place? The first reason is that requirements
+
+4
+00:00:09,130 --> 00:00:12,370
+change, and when the requirements change, we often need to change our
+
+5
+00:00:12,370 --> 00:00:16,356
+design accordingly. In other cases if any of the requirements unchange,
+
+6
+00:00:16,356 --> 00:00:19,690
+we might need to improve our design. And this happens for many
+
+7
+00:00:19,690 --> 00:00:22,300
+reasons. For example, we need to add a new feature, we
+
+8
+00:00:22,300 --> 00:00:25,330
+want to make the code more maintainable, and also in general programmers
+
+9
+00:00:25,330 --> 00:00:28,110
+don't come up with the best design the first time. So they might
+
+10
+00:00:28,110 --> 00:00:31,130
+need to adapt it after the fact. And the final reason I want to
+
+11
+00:00:31,130 --> 00:00:33,040
+mention is sloppiness, and to some
+
+12
+00:00:33,040 --> 00:00:35,700
+extent laziness, of programmers. And a typical
+
+13
+00:00:35,700 --> 00:00:38,520
+example of this is something that we all have done, which is copy
+
+14
+00:00:38,520 --> 00:00:41,890
+and paste programming. So instead of rewriting a new piece of code, because
+
+15
+00:00:41,890 --> 00:00:44,620
+we know that there is some code in some other parts for the
+
+16
+00:00:44,620 --> 00:00:47,900
+program that does a similar thing, we'll just copy the code over. And
+
+17
+00:00:47,900 --> 00:00:51,080
+before we know, we end up with tons of copies of the same functionality.
+
+18
+00:00:51,080 --> 00:00:54,150
+And when that happens, a good way of consolidating that code and
+
+19
+00:00:54,150 --> 00:00:57,580
+extracting that functionality is to use refactoring, for example, by creating a
+
+20
+00:00:57,580 --> 00:01:01,080
+method or a class that provides the functionality. And we'll see specific
+
+21
+00:01:01,080 --> 00:01:03,830
+examples of that. A question I would like to ask at this
+
+22
+00:01:03,830 --> 00:01:07,330
+point of the class is whether you have used refactoring before? So
+
+23
+00:01:07,330 --> 00:01:09,690
+I want you to take a second and think about it. And
+
+24
+00:01:09,690 --> 00:01:12,590
+no matter what you're history is, if you ever coded I bet
+
+25
+00:01:12,590 --> 00:01:16,180
+you any money that the answer is yes, you have done refactoring.
+
+26
+00:01:16,180 --> 00:01:17,300
+What do I mean? I'm going to give you an
+
+27
+00:01:17,300 --> 00:01:19,610
+example. I'm sure you renamed the class or a
+
+28
+00:01:19,610 --> 00:01:22,190
+method or change the name of some variables in
+
+29
+00:01:22,190 --> 00:01:25,490
+the code before. That's refactoring. Even something as simple as
+
+30
+00:01:25,490 --> 00:01:28,030
+renaming a class is refactoring, because, for example, it
+
+31
+00:01:28,030 --> 00:01:30,230
+might help you making your code more understandable. And of
+
+32
+00:01:30,230 --> 00:01:32,520
+course I'll admit that in this case, this is
+
+33
+00:01:32,520 --> 00:01:35,690
+a trivial refactoring, and there are much more interesting ones.