1 files changed, 143 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt
new file mode 100644
index 0000000..0aae00c
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt
@@ -0,0 +1,143 @@
+1
+00:00:00,150 --> 00:00:02,520
+Now that we saw a number of refactorings, we also saw
+
+2
+00:00:02,520 --> 00:00:05,950
+how refactorings can be performed automatically within an ID, I'd like
+
+3
+00:00:05,950 --> 00:00:09,230
+to make you aware of some risks involved with the user
+
+4
+00:00:09,230 --> 00:00:12,510
+refactorings. Refactorings are a very powerful tool, but you also have to
+
+5
+00:00:12,510 --> 00:00:15,820
+be careful, first of all when you do more complex refactorings,
+
+6
+00:00:15,820 --> 00:00:18,540
+you may also introduce subtle faults. What, we don't really call
+
+7
+00:00:18,540 --> 00:00:21,040
+regression errors. You might change something in the class. You might
+
+8
+00:00:21,040 --> 00:00:23,140
+think that that's a behavior preserving
+
+9
+00:00:23,140 --> 00:00:25,200
+transformation when considering the whole code,
+
+10
+00:00:25,200 --> 00:00:27,860
+and instead your change is affecting the behavior of some of the
+
+11
+00:00:27,860 --> 00:00:30,980
+other parts of the code. So, it's introducing a regression that will cause
+
+12
+00:00:30,980 --> 00:00:32,670
+some other functionality, some other piece
+
+13
+00:00:32,670 --> 00:00:34,320
+of functionality some other feature, to
+
+14
+00:00:34,320 --> 00:00:37,190
+work incorrectly. So you always have to be careful, and as we saw
+
+15
+00:00:37,190 --> 00:00:39,750
+at the beginning one way to avoid that is to run tests.
+
+16
+00:00:39,750 --> 00:00:43,080
+Every time you make a refactoring every time you change your code and
+
+17
+00:00:43,080 --> 00:00:46,280
+refactor your code. So is to get the least some confidence in
+
+18
+00:00:46,280 --> 00:00:47,540
+the fact that your refactoring is
+
+19
+00:00:47,540 --> 00:00:50,290
+indeed behavior preserving. Also consider the refactoring
+
+20
+00:00:50,290 --> 00:00:54,680
+should not. Be abused. Refactoring should be performed when it's needed. It's
+
+21
+00:00:54,680 --> 00:00:57,570
+useful to improve the design of your code when you see problems
+
+22
+00:00:57,570 --> 00:00:59,680
+with the design of the code. Shouldn't just be applied for the
+
+23
+00:00:59,680 --> 00:01:02,720
+final code because you can apply, for example, easily within a tool.
+
+24
+00:01:02,720 --> 00:01:06,030
+So be careful not over doing it when you refactor. And for
+
+25
+00:01:06,030 --> 00:01:08,310
+the same reason that we mentioned at the beginning, you should be
+
+26
+00:01:08,310 --> 00:01:10,600
+particularly careful when you're using refactoring
+
+27
+00:01:10,600 --> 00:01:12,290
+for systems that are in production.
+
+28
+00:01:12,290 --> 00:01:15,260
+Because if you introduce a problem, before the system goes in production,
+
+29
+00:01:15,260 --> 00:01:16,750
+then you might be able to catch it earlier,
+
+30
+00:01:16,750 --> 00:01:19,780
+with testing. Or before it's released. But, if you introduce
+
+31
+00:01:19,780 --> 00:01:21,750
+a problem for a system in production, then you have
+
+32
+00:01:21,750 --> 00:01:24,440
+to issue a new version of the code. You'll be
+
+33
+00:01:24,440 --> 00:01:26,860
+affecting, you might be affecting some users, because the code
+
+34
+00:01:26,860 --> 00:01:29,050
+fails on their machine. So, you have to be twice
+
+35
+00:01:29,050 --> 00:01:31,190
+as careful, when you are doing refactoring, when you're changing
+
+36
+00:01:31,190 --> 00:01:33,010
+your code for a system that is already in production.