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.