技术同学如何快速熟悉业务

昨天星球里有同学问了一个问题：刚进入一个复杂的项目里，有什么梳理业务的技巧，能让人快速熟悉业务上手项目。星球里其他同学给出了很多建议，比如：

• 画业务流程图；

• 找有经验的人讲解；

• 先从小模块做起来再说；

• 熟悉系统架构和功能模块；

从我的角度来说，这些建议都是基于自身的经验从某些角度给出的可行的方式。但在实际工作中，每个人的经验不同，项目类型不同，项目迭代方式、业务类型和技术实现都不一样，很难说可以完全借鉴。

这篇文章，我会结合这些同学的建议，以及自己的实践经验，总结几点我认为比较通用的熟悉业务的方法。

PRD 和原型图

要了解一个项目的业务，PRD 和原型图永远是第一选择。这里分两种情况：

未上线项目：如果项目还没上线，目前处于需求和研发阶段，那了解业务最快的办法就是通过 PRD 和原型图。这个阶段的重点并不是了解业务的详细逻辑和场景，而是对业务的整体结构和重要组成模块以及主流程有一定了解。了解这些之后，便于开展接下来的工作。

已上线项目：如果是已经上线的项目，要熟悉业务其实更简单，注册一个测试账号，按照 PRD 和原型图将主要的业务流程走一遍，遇到不太理解的部分，看一下该业务模块对应的测试用例即可。

测试用例和接口文档

上面讲到了熟悉项目业务的第一原则：对业务的整体结构和重要组成模块以及主流程有一定了解。那第二步就很具体了，即了解具体功能模块的业务场景和分支逻辑。这里同样有两个比较通用的方法：

测试用例：设计测试用例的过程，其实就是分析和拆解业务场景逻辑的过程。在通过测试用例熟悉业务的过程中，重点关注正向、逆向、异常和分支四种类型。无论是测试还是开发同学，都可以通过这四个维度去了解业务，有空的话可以用思维导图的方式将用例描述的业务场景按照自己的了解重新绘制一遍，这样可以加快对业务的理解。

接口文档：虽然本文要讨论的是熟悉业务，但理解业务背后的技术实现也是很重要的，而接口文档在我看来就是最好的一种方式。接口文档包含请求的路径、具体的参数名称和值，结合测试用例，可以更快的了解具体的业务场景在不同的逻辑下走向和处理结果。当然，如果没有接口文档，可以通过抓包（已上线项目）或者 code review（项目未上线）方式来理解具体业务场景的实现和处理逻辑。

系统架构图和业务流程图

了解业务的整体结构和组成模块以及具体业务的实现细节和处理逻辑之后，可以回过头来再看看系统架构图以及业务流程图。主要原因如下：

• 将对业务的理解从单点变成全链路；

• 了解业务模块和应用服务的对应关系（便于测试用例的设计和验证）；

• 通过业务流程图来理解服务之间的上下游依赖关系（便于定位分析问题）；

在实际工作中我们会发现，项目会将不同的模块划分给对应的人去负责，这就可能会导致负责的人只对自己负责的模块熟悉，对其他业务模块和整体的业务结构缺乏了解。这样就会出现一些问题，比如出现问题时分析定位耗时较久，要做全流程的业务功能验证需要很多人来配合才能开展。

当然，如果没有系统架构图和业务流程图，可以在对业务和系统有一定的了解后，按照自己的理解绘制出来，这样既可以帮助自己理解业务和系统，同时也可以为其他同学带来一定帮助和参考。

上述的内容主要是从个人的角度来描述如何熟悉业务和系统。从团队的角度来说，一个新人加入团队或者项目后，安排老带新熟悉项目，以及定时的团队内部业务流程 &技术方案串讲，也是很有必要的一件事。

总结来说，刚进入一个新项目，可以先通过 PRD 和原型图对业务的整体结构和重要组成模块以及主流程有一定了解，然后通过测试用例和接口文档了解具体功能模块的业务场景和分支逻辑，最后通过系统架构图和业务流程图将之前单点的内容串联起来，类似总分总的方法，来熟悉项目整体的业务和背后的技术实现。