MUYI · 后端工程师的生产级知识体系

Appearance

如何快速熟悉一个新的系统 ​

方法论定位：接手陌生系统的"降维打击"套路。核心理念是由外到内、由静到动、由看到做。先从用户视角看功能，再下到代码与数据，最后必须动手做一个小需求，把认知变现。

原始七步（原文） ​

1、要一个测试账号，把相关功能走一遍。这样能快速了解一个系统的功能；

2、 看关键的核心表结构，这样可以快速了解系统的领域模型；

3、根据功能步骤找到系统对外的接口列表，了解系统的L0业务流程；

4、下载系统工程，熟悉整个工程结构和模块职责；

5、以一个最重要的流程为入手点，阅读代码。看清楚核心的执行逻辑，可以变看边画时序图；

6、制造一个debug场景，以debug方式走一遍流程。这样可以实际加深对系统的理解；

7、做一个小需求，掌握相关的流程和权限；

一、把七步收敛成五步法 ​

原文七步是操作清单，加上两块常被遗漏的内容（变更历史、工具化），可以收敛成五个阶段：

① 文档与功能层（原文 1、3）   → 这个系统对外"是什么"
② 运行时层（原文 4、5、6）    → 跑起来之后"怎么工作"
③ 数据流层（原文 2）          → 数据"长什么样、怎么流"
④ 变更历史层（补充）          → 系统"最近怕什么"（git log/发布/故障复盘）
⑤ 抓手小需求（原文 7）        → 亲自下场"做一件小事"验证认知
        由外到内 ──► 由静到动 ──► 由看到做

二、五步法详解 ​

1）文档与功能层

  • 拿测试账号把核心功能当用户走一遍：下单、审批、查询各走一次，比读十页设计文档都快；
  • 对外接口清单（swagger/apifox/yapi）按功能分组过一遍，画出 L0 业务流程图；
  • 产出物：一页纸系统画像——系统职责、上下游依赖、核心接口、部署形态。

2）运行时层

  • 工程结构：模块划分即职责划分，先看依赖方向（谁依赖谁），再看入口（Controller/MQ Listener/定时任务）；
  • 选一条最重要的主链路读代码，边读边画时序图，主流程通了再啃异常分支；
  • 制造一个 debug 场景断点走一遍——静态读码是"我以为"，debug 是"它真是"；
  • 产出物：核心链路时序图 + 启动/部署文档。

3）数据流层

  • 核心表结构就是领域模型：主表、状态字段、关联关系，画出 ER 图；
  • 追一条数据的完整旅程：从哪个接口进来、落哪张表、发什么消息、被谁消费、最后归档到哪；
  • 产出物：领域模型 ER 图 + 关键状态机表（订单/工单的状态流转）。

4）变更历史层（最容易被忽略）

  • git log 看最近半年的高频改动目录——改动最频繁的地方就是风险和业务重心所在；
  • 翻发布记录与故障复盘文档，看这个系统"历史上死过几次、都怎么死的"；
  • 产出物：风险热力图（改动热区 + 历史事故点），这决定后续改动要在哪里小心。

5）抓手小需求

  • 主动认领一个小需求/小 bug，完整走一遍开发→评审→测试→发布全流程；
  • 目的不是产出，而是打通流程：权限怎么申请、分支怎么拉、谁审批、怎么发布、怎么看线上验证；
  • 做完这一步，前面四步的认知才算被验证过。

三、工具清单 ​

目的工具/手段
调用链还原SkyWalking / Zipkin / OpenTelemetry，拉一条真实请求看 span 耗时分布
日志检索ELK / Kibana，按 traceId、订单号精确串联一次请求的全链路日志
ER 图DataGrip / Navicat 逆向生成，再人工梳理核心表关系
时序图PlantUML / draw.io，边读码边画，读完图即产出
运行时观测IDE 断点调试（测试环境）；线上用 Arthas 的 watch/trace/ttp 不重启观测方法参数与耗时
变更历史git log --since、release note、故障复盘 wiki
接口契约swagger / apifox / yapi
容量与依赖监控大盘（QPS/RT/错误率）、中间件依赖清单

四、一周上手实操路线 ​

时间动作产出
Day 1申请账号与权限，把核心功能走一遍；看接口文档系统画像一页纸
Day 2拉工程本地跑起来，过模块结构与依赖方向工程结构图（手绘即可）
Day 3读最重要的一条主链路，边读边画时序图核心链路时序图
Day 4制造 debug 场景走断点；看核心表，画 ER 图ER 图 + 状态机表
Day 5git log 看热区与复盘；认领第一个小需求风险热力图 + 进入实战

配套动作：每天花 30 分钟向 mentor 复述当天理解（能讲清楚才算懂，讲不清的正是第二天的目标）。

五、避坑 ​

  • 只读代码不跑系统：认知停留在猜测层，一个 debug 抵一小时的静态阅读；
  • 从工具类/util 读起：应该从主链路的入口读起，工具类是遇到再看；
  • 只学不产出：不画图、不复述、不做题，一周后忘掉大半——输出促使输入；
  • 一上来就想搞懂所有分支逻辑：先主干后枝叶，异常分支在做需求时自然会碰到。

2026-10 扩充（原内容过薄）。