如何学习一个新的系统

学习系统主要分为三个部分

一、业务学习可以从如下几点寻找答案

系统所在行业的情况是怎样？

系统的目标用户是谁？比如是给公司高层做决策用？给运营或客服用？还是互联网用户用？

平均有多少人在使用？高峰期多有少人在用？

系统有什么业务价值？有哪些指标可以衡量系统业务价值？

系统有哪些功能模块？

系统有哪些领域概念？梳理下系统的领域模型。

系统的关键业务流程有哪些？关键业务流程是怎样？

系统的非功能性需求有哪些？如性能、质量、扩展性、安全性等。

系统未来的发展规划是怎样？

二、技术学习

技术学习主要学习系统的架构、如何实现、系统的运维等。描述一个系统的架构有五视图方法论，五视图分别是：逻辑架构、开发架构、运行架构、物理架构、数据架构。

【1】逻辑架构

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

常见问题：

有哪些子系统或模块？系统之间是什么样的关系？

对外上下游接口有哪些？对接人是谁？

关键业务流程怎么实现的？用类图、序列图等方式表达出来。

【2】开发架构

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

常见问题：

代码在哪？

包怎么划分的？怎么分层？如 mvc、controller-service-dao。

用了什么框架？如 ssh、dubbo。

用了哪些工具包？如 apache commons、guava。

用了哪些中间件？如 kafka、windQ、ucc，scm，rsf等，

依赖哪些平台？如scm,windQ,kafka，duts等。

【3】运行架构

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

常见问题：

系统能支撑多少 qps ？峰值 qps 多少？

与上下游系统怎么交互的？rpc？http？同步还是异步？

【4】物理架构

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

常见问题：

系统如何发布部署？有哪些部署环境？

系统有多少台机器？

系统部署怎么部署的？关注接入层，部署方式，如集群部署、分布式部署等。

有没有容器化？

有没有多机房部署？

【5】数据架构

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

常见问题：

数据存储在哪？用了什么数据库，如 oracle、mysql。

梳理 E-R 图。

数据量有多少？是否有分库分表？

用了哪些 nosql 库？

有哪些数据同步任务？

大数据框架的使用情况如何？

【6】系统运维

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

常见问题：

什么时间容易出问题？比如电商双十一，对系统的压力很大，这时候很容易出问题。

对关键功能是否有监控？需要看系统有配置了哪些报警项，监控了哪些方面。

出了问题怎么解决？日志在哪？是否有全链路跟踪？是否有一些紧急操作，比如开关配置、降级、限流配置。

系统有哪些坑？找开发同学回顾历史问题，以免踩坑。通过同事总结的 case，或者与负责的产品、运营、技术与了解。系统总会有一些坑，需要把这些坑填上。历史代码经过多次迭代总会导致复杂度高（分支、嵌套、循环很多），存在设计漏洞，性能隐患等，很难维护，这些就需要我们去重构了。记住有一句话：填的坑越大，能力越大。

运营、客服反馈的常见问题有哪些？

三、实战

做需求、修 bug、重构等方式，亲自动手编码、调试、测试、上线。