1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
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.
|
