1 files changed, 0 insertions, 143 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
deleted file mode 100644
index 0aae00c..0000000
--- a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt
+++ /dev/null
@@ -1,143 +0,0 @@
-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.