原文地址:https://mp.weixin.qq.com/s/J8eK-qRMkmHEQZ_dVts9aQ?poc_token=HMA-_mWjfcDmGVW6hXX1xEDDvuJPE3pL9-8uSlyY
导读：本文总结了熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。
前言
开发人员经常会面临下面一些场景：
- 新人入职，需要学习已有系统，作为 landing 的一部分，如何学习？
- 被拉过去参与一个陌生系统的迭代开发或者系统维护（bugfix），如何快速上手？
- 同事离职或转岗，需要把系统交接给你，怎么去接？ 内心 os：这是一口锅吗？
这样的场景多了，就需要去梳理常见问题以及应对方法，方便后续遇到类似场景可以快速应对。
业务学习
业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。
不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。
常见问题：
- 系统所在行业的情况是怎样？
- 系统的目标用户是谁？比如是给公司高层做决策用？给运营或客服用？还是互联网用户用？
- 平均有多少人在使用？高峰期有多少人在用？
- 系统有什么业务价值？有哪些指标可以衡量系统业务价值？
- 系统有哪些功能模块？
- 系统有哪些领域概念？梳理下系统的领域模型；
- 系统的关键业务流程有哪些？关键业务流程是怎样？
- 系统的非功能性需求有哪些？如性能、质量、扩展性、安全性等；
- 系统未来的发展规划是怎样？
技术学习
技术学习主要学习系统的架构、如何实现、系统的运维等。描述一个系统的架构有五视图方法论。
五视图分别是：
- 逻辑架构
- 开发架构
- 运行架构
- 物理架构
- 数据架构
1. 逻辑架构
逻辑架构着重考虑功能需求，系统应当向用户提供什么样的服务，关注点主要是行为或职责的划分。
常用表达图形，静态图有包图、类图、对象图；动态图有序列图、协作图、状态图、活动图。逻辑架构的核心设计任务是模块划分、接口定义、领域模型细化。
常见问题：
- 有哪些子系统或模块？系统之间是什么样的关系？
- 对外上下游接口有哪些？对接人是谁？
- 关键业务流程怎么实现的？用类图、序列图等方式表达出来。
2. 开发架构
开发架构关主要关注系统源代码、第三方 SDK、使用的框架、中间件、工具包。
常见问题：
- 代码在哪？
- 包怎么划分的？怎么分层？如 mvc、controller-service-dao；
- 用了什么框架，如 ssh、dubbo；
- 用了哪些工具包？如 apache commons、guava；
- 用了哪些中间件？如 metaq、tair、schedulerX、Diamond；
- 依赖哪些平台？如权限平台、流程引擎等。
3. 运行架构
运行架构的着重考虑运行期质量属性，关注点是系统的并发、同步、通信等问题，这势必涉及到进程、线程、对象等运行时概念，以及相关的并发、同步、通信等。
常见问题：
- 系统能支撑多少 qps？峰值 qps 多少？
- 与上下游系统怎么交互的？rpc？http？同步还是异步？
4. 物理架构
物理架构的设计着重考虑安装和部署需求，关注点是目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性、持续可用性、性能和安全性等要求。
常见问题：
- 系统如何发布部署？有哪些部署环境？
- 系统有多少台机器？
- 系统部署怎么部署的？关注接入层，部署方式，如集群部署、分布式部署等
- 有没有容器化？
- 有没有多机房部署？
5. 数据架构
数据架构的设计着重考虑数据需求，关注点是持久化数据的存储方案，不仅包括实体及实体关系数据存储格式，还可能包括数据传递、数据复制、数据同步等策略。
常见问题：
- 数据存储在哪？用了什么数据库，如 oracle、mysql；
- 梳理 E-R 图；
- 数据量有多少？是否有分库分表？
- 用了哪些 nosql 库？
- 有哪些数据同步任务？
- 大数据框架的使用情况如何？
6. 系统运维
系统运维重点关注什么时候会出问题，出了问题怎么解决。
常见问题：
- 什么时间容易出问题？比如电商 双11，对系统的压力很大，这时候很容易出问题；
- 对关键功能是否有监控？需要看系统有配置了哪些报警项，监控了哪些方面；
- 出了问题怎么解决？日志在哪？是否有全链路跟踪？是否有一些紧急操作，比如开关配置、降级、限流配置；
- 系统有哪些坑？找开发同学回顾历史问题，以免踩坑。通过同事总结的 case，或者与负责的产品、运营、技术与了解。系统总会有一些坑，需要把这些坑填上。历史代码经过多次迭代总会导致复杂度高（分支、嵌套、循环很多），存在设计漏洞，性能隐患等，很难维护，这些就需要我们去重构了。记住有一句话：填的坑越大，能力越大；
- 运营、客服反馈的常见问题有哪些？
实践
熟悉了系统的业务和技术后，就要实战了，通过实战进一步加深对系统的熟悉程度。实践可以通过做需求、修 bug、重构等方式，亲自动手编码、调试、测试、上线。
总结
已有系统通常经历了从 0 到 N 的建设过程，熟悉系统其实是一个逆向推导过程，也是一个学习架构、阅读源码的过程。
在学习的过程中最好能带上思考，比如为什么要这么设计？为什么要用这个中间件？是否有更好的编码方式？哪些地方可以优化等，以此达到一个深入熟悉的过程。
