系统老化与重构

架构老化源于什么？

在我们不断给系统添加各种新功能的时候，往往会遇到功能需求的实现方式不在当初框架的设定范围之内，于是很多功能代码逸出框架的范围之外。

代码老化的标志

添加功能越来越难，迭代效率降低，问题却持续不断，解决了一个问题却由此生出好几个问题。

怎么应对架构老化？

• 该怎么重构系统，才能让我们的软件重新恢复活力？
• 在重构系统之前，我们应该如何进行局部改善，如果增加新功能又应该如何考虑？

老系统添加新功能

让新功能的代码与既有系统解耦，能不依赖尽量不依赖。

**不依赖的核心含义是业务不依赖。**新功能的绝大部分代码独立于既有业务系统，只有少量桥接的代码是耦合的。

公司内部的依赖库需要辩证地看，基本的判断标准是成熟度越高的基础库越值得依赖。

做新功能的思路：尽可能与既有系统剥离，从独立业务视角去实现业务，抽象对环境的依赖。最后，用最少量的对接代码把整个系统串起来。

1. 架构的局部优化

目标是优化某个功能与核心系统的耦合关系。

1.1 重写/局部重构

从系统中彻底移除掉与该功能相关的代码，重新写一份新的。

局部重构一定要发生在你对这块代码的业务比较了解的情形，比如你已经维护过它一阵子了。另外，局部重构一定要把老代码清理干净，不要残留一些不必要的代码在系统里面。

1.2 依赖优化（将散落在系统中的代码集中起来）

依赖优化工作量小:

• 做的是代码搬运，不改变任何业务逻辑。
• 可以不必深入功能的细节，只需要找到该功能的所有相关代码，这是难点，然后把它们集中起来。

尽可能把我们认为非核心系统的功能，都基于依赖优化的方式独立出去。 这样核心系统与周边系统的耦合就理清楚了。

2. 核心系统重构（高风险）

确定要对核心系统进行重构，那么最高优先级是确定它的边界，也就是使用界面（接口）

周边系统对核心系统的依赖：

• 核心系统的功能，表现为它提供的 DOM 接口
  • 让周边系统对它的依赖，变成依赖接口，而非依赖实现；
  • 审视核心系统功能的 DOM 接口的合理性，明确出我们期望的接口设计。
• 核心系统提供的事件，让周边系统能够介入它的业务流程
  • 对所有周边模块进行依赖优化的整理，细加分析后可以初步确定核心系统需要暴露的事件集合。

最重要的是对核心系统的接口进行重新设计。

• 我们对业务的理解的确有了长足的进步。
• 对周边系统切换到新接口的成本有充足的预计。

实际上从难度来说，重构比一个全新业务的架构过程要难得多。重构，不只是一个架构的合理性问题。它包含了架构合理性的考量，因为我们需要知道未来在哪里，我们迭代方向在哪里。