1 files changed, 67 insertions, 0 deletions
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt
new file mode 100644
index 0000000..6104ae0
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt
@@ -0,0 +1,67 @@
+1
+00:00:00,180 --> 00:00:03,560
+And sometimes, architectural drift and erosion gets you so
+
+2
+00:00:03,560 --> 00:00:06,450
+far away from the point where your software architecture should
+
+3
+00:00:06,450 --> 00:00:10,476
+be, that your architecture is completely degraded. And at this
+
+4
+00:00:10,476 --> 00:00:13,290
+point, you have two main options. The first option is
+
+5
+00:00:13,290 --> 00:00:17,140
+to keep frantically tweaking the code. And this normally leads
+
+6
+00:00:17,140 --> 00:00:20,370
+to disaster. Why? Because you only make things worse. You
+
+7
+00:00:20,370 --> 00:00:22,570
+don't know exactly what you are changing and therefore, you're
+
+8
+00:00:22,570 --> 00:00:25,570
+basically stabbing in the dark, trying to fix your system.
+
+9
+00:00:25,570 --> 00:00:27,580
+The other possiblity is that you can try to
+
+10
+00:00:27,580 --> 00:00:29,830
+determine the software system architecture
+
+11
+00:00:29,830 --> 00:00:31,710
+from its implementation level artifacts,
+
+12
+00:00:31,710 --> 00:00:34,520
+so you try to derive what the architecture is
+
+13
+00:00:34,520 --> 00:00:36,610
+and try to fix it, once you have derived the
+
+14
+00:00:36,610 --> 00:00:39,266
+architecture. And this is what is normally called, architectural
+
+15
+00:00:39,266 --> 00:00:44,210
+recovery, determining a software architecture from an implementation and fixing
+
+16
+00:00:44,210 --> 00:00:46,410
+it. And as you can imagine, this is normally
+
+17
+00:00:46,410 --> 00:00:49,330
+a more recommended way to go than the first solution.