架构的老化

功夫皆在平常

我们不能指望有一天架构水平会突飞猛进。架构能力提升全靠平常一点一滴地不断反思与打磨得来。

架构老化源于什么?

添加新功能的时候,功能需求不在框架的范围之内,很多功能代码逃出框架范围之外

代码老化的标志

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

理想情况

坚持以 “最小化的核心系统 + 多个相互正交的周边系统” 这个指导思想来构建应用,那么代码就很难出现老化

不可避免的情况

有很多原因会导致架构老化难以避免,比如

  • 工程师只考虑实现不考虑长时间的可维护性
  • 代码没有review,直接提交
  • 需求理解不够深刻,不能保证长期迭代要求
  • 架构迭代不及时,直接打补丁

怎么应对架构老化?

  1. 如何重构系统?
  2. 如何做到局部改善?如何处理新增的新功能?

老系统如何 增加新功能

通常我们应该把自己要添加的功能定位为周边功能。对于周边功能,往往考虑最多的点是如何少给核心系统添加麻烦,能够少改就少改。

实际上当我们视角放在周边系统的时候,其实它本身也应该被看作独立业务系统。

如何让新功能的代码与既有系统解耦,能够不依赖尽量不依赖?

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

我根据文字绘制的图如下所示:

未命名文件.png

  1. 不依赖的另一个重要话题是要不要依赖公司内部的基础库。

这一点需要辩证来看,不能简单回答依赖或不依赖。完全不依赖意味着放弃生产力。

未命名文件 (1).png

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

架构的局部优化

局部优化.png

依赖优化的好处比较明显。

  • 工作量小,做的是代码搬运,不改变任何业务逻辑
  • 可以不必深入功能的细节,只需要找到该功能的所有相关代码

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

核心系统重构

考虑风险

  • 牵一发而动全身,我们无法保证工程的交付周期
  • 没有谁对全局有足够的了解,重构会过于盲目,项目的执行风险难以把控。

能够在不修改实现的情况下调整核心系统的使用界面到我们期望的样子是最好的。

周边系统对核心系统的依赖分类:

  • 核心系统为周边系统提供的 DOM 接口
  • 核心系统提供的事件,让周边系统能够介入它的业务流程

抽象核心模块的步骤:

  • 让周边系统对它的依赖,变成依赖接口,而非依赖实现
  • 审视核心系统功能的 DOM 接口的合理性,明确出我们期望的接口设计

核心系统的接口进行重新设计。这一步的难点在于:

  • 我们抽象的业务接口有了更加精炼符合业务本质的表达方式,而不是换汤不换药,否则我们就需要质疑这次重构的必要性
  • 对周边系统来说,这是从老接口过度到新接口的过程。虽然理论上让核心系统维护两套 DOM 接口同时存在,在技术上是可行的,但是这个过渡期不能太长,否则容易让人困惑,不清楚我们倡导的是什么

核心系统,每一个周边系统,彼此完全独立,可以单独调整和优化。嫌当前的核心系统太糟糕?那就搞搞。为什么可以这么轻松决策?因为就算我们要重新写核心系统,要做的事情也很收敛,不会影响到大局

标签: 架构, 代码, 模块, 系统, 周边, 核心, 功能, 框架, 业务, 接口, 依赖, 抽象

知识共享许可协议
本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

发送一条友善的评论

  • 目录