架构老化与重构？我们可以从哪些维度下手

架构老化源于什么？

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

这些散落在各处的代码，把系统绞得支离破碎。久而久之，代码就出现老化，散发出臭味。

在理想的情况下，如果我们坚持以 “最小化的核心系统 + 多个相互正交的周边系统” 这个指导思想来构建应用，那么代码就很难出现老化。

老系统怎么添加新功能

正常来说，我们添加功能的时候，尤其是自己加入项目组比较晚，已经有大量的历史代码沉淀在那里的时候，通常我们应该把自己要添加的功能定位为周边功能。对于周边功能，往往考虑最多的点是如何少给核心系统添加麻烦，能够少改就少改

但是，这其实还不够。实际上当我们视角放在周边系统的时候，其实它本身也应该被看作独立业务系统。这样看的时候，我们自然而然会有新的要求：如何让新功能的代码与既有系统解耦，能够不依赖尽量不依赖。

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

架构的局部优化

一种是重写，或者叫局部重构。它相当于从系统中彻底移除掉与该功能相关的代码，重新写一份新的。这和开发一个新功能没什么两样，最多看看被移除的代码里面，有哪些函数设计比较合理，可以直接拿过来用，或者稍微重新包装一下能够让规格更合理的。

另一种是依赖优化。它关注的重心不是某项功能本身的实现，而是它与系统之间的关系。

依赖优化整体上做的是代码的搬运工。怎么搬代码？和删除代码类似，我们要找到和该功能相关的所有代码。但是我们做的不是删除，而是将散落在系统中的代码集中起来。我们把对系统的每处修改变成一个函数，比如叫 doXXX_yyyy。这里 XXX 是功能代号，yyyy 则依据这段搬走的代码语义命个名。

核心系统的重构

周边系统对核心系统的依赖无非两类：一是核心系统的功能，表现为它提供的 DOM 接口；二是核心系统提供的事件，让周边系统能够介入它的业务流程。

进一步要做的事情是把核心系统的 DOM 接口也抽象出来。这一步比较复杂。它包含两件事情：让周边系统对它的依赖，变成依赖接口，而非依赖实现；审视核心系统功能的 DOM 接口的合理性，明确出我们期望的接口设计。

我们需要对核心系统的接口进行重新设计。

这一步的难点在于：第一，我们对业务的理解的确有了长足的进步。我们抽象的业务接口有了更加精炼符合业务本质的表达方式，而不是换汤不换药，否则我们就需要质疑这次重构的必要性。

第二，对周边系统切换到新接口的成本有充足的预计。对周边系统来说，这是从老接口过度到新接口的过程。虽然理论上让核心系统维护两套 DOM 接口同时存在，在技术上是可行的，但是这个过渡期不能太长，否则容易让人困惑，不清楚我们倡导的是什么。

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

【总结】

首先是架构设计：

1.需要梳理出当前的现状，对于整体现状做出分析；目的是再烂的架构都有其合理性，其中那些可能会被将来做为最小原子使用这是需要做的；

2.针对分析的结果再权衡利弊的基础上想出改进方案，毕竟重构升级的过程还是有许多关联性的数据；

3.未来的短、中、长期规划大致是怎样，怎样才能可扩展或后期升级。

其次是资源规划与调度：个人觉得这块内容应当属于项目经理的知识；

1.资源规划：要做的就是拆分，需要对于团队/项目有足够的了解才能更好的明白和了解有什么样资源以及可以用到什么样的程度

2.资源调度：任何一个项目会有固定资源和非固定/调用资源，固定和非固定的使用程度和时间完全不同的且了解不同，这个协调能力是一个项目经理所需的能力。

3.最后是阶段规划以及持久性：格局观和可持续性，即通常所说的CI/CD特性；对于整体的了解越明白、格局观与弹性越好，规划和持续性就越好。其实还涉及到产品中常用的MVP特性，试错中找到最佳持续方案。

原文始发于微信公众号（二进制跳动）：架构老化与重构？我们可以从哪些维度下手

文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/167421.html