如何熟悉一个系统？

前言

开发人员经常会面临下面一些场景：

• 新人入职，需要学习已有系统，作为 landing 的一部分，如何学习？
• 被拉过去参与一个陌生系统的迭代开发或者系统维护（bugfix），如何快速上手？
• 同事离职或转岗，需要把系统交接给你，怎么去接？ 内心 os：这是一口锅吗？

这样的场景多了，就需要去梳理常见问题以及应对方法，方便后续遇到类似场景可以快速应对。本文总结熟悉系统主要分四部分：熟悉业务、熟悉技术、熟悉人、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。

熟悉业务

系统通过XX功能为XX用户(角色）提供XX价值。

分类	详情	方法	产出
角色	用户是谁？有哪几类角色？		角色表
价值	系统整体价值是什么？为每个用户提供什么价值？有哪些指标衡量系统业务价值？	这个业务解决了什么痛点？
功能	涉及哪几个子系统？ 有哪些功能模块？ 系统有哪些领域概念？	跟产品、运营、开发沟通。 产品白皮书、PRD； 申请个测试账号用一下；	产品功能架构图、功能树、用例图
流程	每个角色流程是什么样的？最核心的是信息流	流程图 了解关键节点的输入输出，	业务流程图（多个）
上下游	关联系统有哪些，上下游
规划	系统未来的发展规划是怎样？ 现在业务遇到了什么瓶颈？准备如何破局	参考业务规划、产品规划、客户走访
人员	PM、运营、FE、QA对接人		干系人列表

业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。

常见问题：

• 系统所在行业的情况是怎样？
• 系统的目标用户是谁？比如是给公司高层做决策用？给运营或客服用？还是互联网用户用？
• 平均有多少人在使用？高峰期有多少人在用？
• 系统有什么业务价值？有哪些指标可以衡量系统业务价值？
• 系统有哪些功能模块？
• 系统有哪些领域概念？梳理下系统的领域模型；
• 系统的关键业务流程有哪些？关键业务流程是怎样？
• 系统的非功能性需求有哪些？如性能、质量、扩展性、安全性等；
• 系统未来的发展规划是怎样？

熟悉技术

分类	详情	方法	产出
系统架构
领域模型
代码结构	源代码有哪几个工程、工程结构和模块职责	以最重要的流程为入手点，阅读代码，看清楚核心的执行逻辑。 做一个小需求，掌握相关的流程和权限。	可以解决线上问题；可以实现新的业务功能。
细节	关键对外接口、涉及的DTS、缓存、MQ、Job、DB、其他；上下游有哪些通过什么形式调用的？

技术学习主要学习系统的架构、如何实现、系统的运维等。描述一个系统的架构有五视图方法论。

五视图分别是：

• 逻辑架构
• 开发架构
• 运行架构
• 物理架构
• 数据架构

逻辑架构

逻辑架构着重考虑功能需求，系统应当向用户提供什么样的服务，关注点主要是行为或职责的划分。常用表达图形，静态图有包图、类图、对象图；动态图有序列图、协作图、状态图、活动图。逻辑架构的核心设计任务是模块划分、接口定义、领域模型细化。

常见问题：

• 有哪些子系统或模块？系统之间是什么样的关系？
• 对外上下游接口有哪些？对接人是谁？
• 关键业务流程怎么实现的？用类图、序列图等方式表达出来。

开发架构

开发架构关主要关注系统源代码、第三方 SDK、使用的框架、中间件、工具包。

常见问题：

• 代码在哪？
• 包怎么划分的？怎么分层？如 mvc、controller-service-dao；
• 用了什么框架，如 ssh、dubbo；
• 用了哪些工具包？如 apache commons、guava；
• 用了哪些中间件？如 metaq、tair、schedulerX、Diamond；
• 依赖哪些平台？如权限平台、流程引擎等。

运行架构

运行架构的着重考虑运行期质量属性，关注点是系统的并发、同步、通信等问题，这势必涉及到进程、线程、对象等运行时概念，以及相关的并发、同步、通信等。

常见问题：

• 系统能支撑多少 qps？峰值 qps 多少？
• 与上下游系统怎么交互的？rpc？http？同步还是异步？

物理架构

物理架构的设计着重考虑安装和部署需求，关注点是目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性、持续可用性、性能和安全性等要求。

常见问题：

• 系统如何发布部署？有哪些部署环境？
• 系统有多少台机器？
• 系统部署怎么部署的？关注接入层，部署方式，如集群部署、分布式部署等
• 有没有容器化？
• 有没有多机房部署？

数据架构

数据架构的设计着重考虑数据需求，关注点是持久化数据的存储方案，不仅包括实体及实体关系数据存储格式，还可能包括数据传递、数据复制、数据同步等策略。

常见问题：

• 数据存储在哪？用了什么数据库，如 oracle、mysql；
• 梳理 E-R 图；
• 数据量有多少？是否有分库分表？
• 用了哪些 nosql 库？
• 有哪些数据同步任务？
• 大数据框架的使用情况如何？

系统运维

系统运维重点关注什么时候会出问题，出了问题怎么解决。

常见问题：

• 什么时间容易出问题？比如电商 双11，对系统的压力很大，这时候很容易出问题；
• 对关键功能是否有监控？需要看系统有配置了哪些报警项，监控了哪些方面；
• 出了问题怎么解决？日志在哪？是否有全链路跟踪？是否有一些紧急操作，比如开关配置、降级、限流配置；
• 系统有哪些坑？找开发同学回顾历史问题，以免踩坑。通过同事总结的 case，或者与负责的产品、运营、技术与了解。系统总会有一些坑，需要把这些坑填上。历史代码经过多次迭代总会导致复杂度高（分支、嵌套、循环很多），存在设计漏洞，性能隐患等，很难维护，这些就需要我们去重构了。记住有一句话：填的坑越大，能力越大；
• 运营、客服反馈的常见问题有哪些？

熟悉人

1）了解组织结构：查看公司的组织树，知道公司大概是如何运作的，以及哪些是KP（Key Person，关键人）。比如，一个典型的电商公司会包括产品部、运营部、销售部、技术部、人力资源部、财务部、法务部等。大公司技术部又分为后端RD、FE、美工、QA、多种运维岗位等。

2）了解人员角色：了解公司都有哪些岗位，以及各岗位的职责范围。

3）拜山头：找到和自己工作息息相关的岗位人员，比如产品和运营。积极和他们沟通，向他们请教业务问题，多多交流。这样一方面可以建立更好的人际关系，另一方面也可以更快地熟悉业务。

实践

熟悉了系统的业务和技术后，就要实战了，通过实战进一步加深对系统的熟悉程度。实践可以通过做需求、修 bug、重构等方式，亲自动手编码、调试、测试、上线。

真实情况

现实中，接手系统时，架构图不准确甚至缺失、无流程图等情况才正常，各文档齐备反而不正常。这时怎么办？

入口最重要，通过入口可以查找到所有相关内容。比如了解系统功能，这时候就可以看到调用的后端接口，进而通过相关接口找到代码、数据库表、发送的MQ、调用的thrift接口。

阅读代码非常关键，对照架构图、流程图等仔细阅读核心代码，才能真正熟悉系统。debug的方式阅读代码能够大大提升效率。

一些监听的MQ需要询问，防止看代码遗漏了这里。

一些核心逻辑，通过别人介绍能比梳理代码节省很多人力。

熟悉系统过程中，要问几个问题：

这个业务为什么是你做？

要对世界的运转以及自己接触的业务保持好奇心。

一个不理解业务的研发和流水线的工人是没有很大区别的。

主管对技术的依赖和诉求是什么？

总结

已有系统通常经历了从 0 到 N 的建设过程，熟悉系统其实是一个逆向推导过程，也是一个学习架构、阅读源码的过程。在学习的过程中最好能带上思考，比如为什么要这么设计？为什么要用这个中间件？有没有更好的编码方式？哪些地方可以优化等，以此达到一个深入熟悉的过程。

如何熟悉一个系统？（内含知识大图）-阿里云开发者社区