1 files changed, 103 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt
new file mode 100644
index 0000000..800ffb5
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt
@@ -0,0 +1,103 @@
+1
+00:00:00,100 --> 00:00:02,469
+A couple of minutes ago we talked about the fact that well, we
+
+2
+00:00:02,469 --> 00:00:05,260
+might need to change our design a lot, so how we going to do
+
+3
+00:00:05,260 --> 00:00:08,540
+that, that's going to be expensive. Well it's not very expensive, if we can
+
+4
+00:00:08,540 --> 00:00:10,876
+do efficient refactoring. Which is another
+
+5
+00:00:10,876 --> 00:00:13,120
+one of the important xp practices. And
+
+6
+00:00:13,120 --> 00:00:15,280
+what does it mean to refactor? It means to take a piece of
+
+7
+00:00:15,280 --> 00:00:19,530
+code who's design might be suboptimal, because for example, we evolved it, we
+
+8
+00:00:19,530 --> 00:00:22,600
+didn't take into account that from the beginning some of the features that
+
+9
+00:00:22,600 --> 00:00:25,110
+had to be added later, probably because we didn't even know about this
+
+10
+00:00:25,110 --> 00:00:28,200
+feature, because the requirements evolved. So we're going to take this piece
+
+11
+00:00:28,200 --> 00:00:31,870
+of code and we're going to restructure it, so that it becomes simple
+
+12
+00:00:31,870 --> 00:00:34,070
+and maintainable. Developers are expected to
+
+13
+00:00:34,070 --> 00:00:35,590
+refactor as soon as opportunities for
+
+14
+00:00:35,590 --> 00:00:39,530
+improvement, are found. And that happens for example, before adding some code.
+
+15
+00:00:39,530 --> 00:00:41,730
+You might look at the code that you're about to modify, or
+
+16
+00:00:41,730 --> 00:00:43,850
+to which you are about to add parts, and say can we
+
+17
+00:00:43,850 --> 00:00:47,060
+change the program to make the addition simple, that has maintainability or
+
+18
+00:00:47,060 --> 00:00:50,220
+we can do it after adding some code to our code base.
+
+19
+00:00:50,220 --> 00:00:52,730
+We might look at the code, the resulting code, and say well
+
+20
+00:00:52,730 --> 00:00:55,770
+can we make the program simpler? Was the running all the tests
+
+21
+00:00:55,770 --> 00:00:57,920
+and the key point here is that we don't want to refactor on
+
+22
+00:00:57,920 --> 00:01:01,580
+speculation, but we want to refactor on demand, on the system, and the
+
+23
+00:01:01,580 --> 00:01:04,840
+process needed. Again the goal is just to keep the code simple
+
+24
+00:01:04,840 --> 00:01:07,680
+and maintainable, not to over do it. And as I mentioned before
+
+25
+00:01:07,680 --> 00:01:10,810
+we're going to have a whole lesson, the next lesson on refactoring. So
+
+26
+00:01:10,810 --> 00:01:13,470
+we're going to go in more depth in the discussion of this topic.