一周格致随想（第19期）如何快速梳理应对遗留系统？

在日常工作中，你是否遇到新交接负责一个老旧系统呢？你是否遇到作为新人要负责一个有很多年的老系统呢？你是否遇到过老系统一点文档都没有，且原负责人员也毕业了的情况呢？

面对种种情况，我们也无法改变，只有承认接受现实。静下心来，静下来……，不要动怒，平静地应对，找到有效快速的方法，并熟悉遗留系统代码，产出自己的文档。这样才能在业务快速发展时，从容地应对遗留系统需要承接的需求。

最近几周，我也遇到这样的情况，新接手一个比较老的系统，系统经过3次转手，且现负责的人员，他们也仅负责了几个月，仅有一些过时的文档，有价值内容也不多。

接下来，我们聊一聊，我是如何快速梳理应对遗留系统？

首先，我们了解下系统的用户有那些？面向C端的用户，面向B端内部的运营人员、面向B端外部供应商/商家人员等。

第二，知道了系统的用户，接下来就是从用户视角，将系统功能模块，结构化拆分归类进行梳理了解系统大致框架内容。系统由那几个子系统，子应用组成。系统提供面向用户有那些UI功能，或者作为微服务提供的接口有那些。

若系统是面向C端用户的，有APP、PC、小程序，每个端的功能模块有那些，功能模块具体业务作用及逻辑是什么。

若系统是面向B端用户，运营端的功能模块都有那些，功能模块提供业务运营具体的业务逻辑是什么。

若系统是面向前台业务应用，中心微服务的功能模块都有那些对外服务接口，有那些Worker批量处理数据。

可以作为一个新注册用户，使用体验一遍完整的系统功能，这样从用户外部视角对整体系统有一个大致体感。

第三，根据页面功能模块，梳理其对应的微服务功能逻辑。主要有服务应用分几层，模块包有那些，服务接口列表，服务的核心业务逻辑，服务依赖外部系统接口有那些，服务数据库表有那些，再详细点知道服务限制条件，异常触发条件有那些，这些是隐藏的逻辑，往往出问题的也是这几点。

我们进行系统功能模块或者服务接口梳理时，一定不要过于纠结细节，陷于方法调用陷阱中，先从大局上分层上，把相同层面维度的模块摸清后，再进行下钻更详细的维度功能逻辑梳理。

这一部分完成后，我们已经知道了系统静态信息，拥有那几类用户，拥有那几个用户端，拥有那几个子系统和应用模块，以及功能模块的大致逻辑。

第二部分，系统的动态信息方面，我们需要从系统交互的路径，业务数据流转环节上进行梳理拆解解，找出系统的关键环节。

首先，系统外部，以系统为中心，从用户操作业务流的正向链路开始，将系统上下游交互流转的路径环节全部探查出来，至到业务生命周期结束环节。比如：用户的注册流程，电商正逆交易链路流程，异常场景处理链路流程。

其次，系统内部，以模块为中心，更进一步细化系统模块的调用交互路径，我们绘制出功能服务模块详细业务时序，业务活动状态变化，知道业务详细逻辑及触发条件。

第三，系统内部，以类对象为中心，梳理功能模块类图，数据表ER关系图，更详细类与类之间的关系，层与层之间的调用关系。

我们通过系统交互路径，数据流链路流转经过关键环节的梳理了解，就能发现系统薄弱点在那里，并知道后续系统优化方案改造点。对于电商业务系统，我们不仅知道系统交互路径的信息流，还要知道资金流，货物流的链路路径。

我们已经知道系统功能模块，以及交互调用路径，那么我们就真实地熟悉并掌握系统了吗？不是的。

因为还有一些更详细的业务逻辑，需要在特定的业务数据场景条件下才能触发，业务不可能给我们更充足的时间去梳理和了解，往往大致了解后，就要进行需求开发了。

所以我们还需要从实际的业务数据，实际的系统运行状态，系统监控指标数据进行观察系统。我们根据用户操作，所影响到实际业务数据变化，来观察预判业务逻辑，有时还要通过实际的业务数据，对预判的结果进行校对，反复迭代，才能更详实地理解业务，理解系统。

我们知道从0到1开发一个新系统需要先进行架构设计，再进行编码开发，最终运行。但是对于遗留系统逻辑的梳理过程，就是一个逆架构设计的过程。

经过以上几个步骤，我们已经熟练掌握遗留系统的逻辑，逆架构设计产出的文档，摸底梳理形成的系统改造点清单，就是我们根据业务模型，重新进行系统二次架构升级的物料。

其实整个逆架构设计梳理过程的方法，我们就是按照C4建模设计方法，在遗留系统中的具体运用。

所谓举一反三，当你真的能熟练掌握在某个领域内拆解系统的能力，那么你就很容易联想到其他领域，类似的情况。你会突然联想到一些不同领域系统架构设计的成功经历，并结合自己的认知来比较，归纳。

面对遗留系统代码时，你说出傻X的次数，可以度量你自己架构设计的水平。

2023/3/5