程序员如何梳理业务

刚工作或者工作一段时间的伙伴应该认识到程序员对于业务了解是多么的重要，如有疑问，可快速看一眼这篇文章。

梳理业务代码的重要性-优快云博客

那如何梳理业务，有没有好的方法？

了解业务的渠道有那些？

1、产品本身，首先要体验一下线上产品，熟悉业务功能。

2、沉淀的资料文档，之前的需求开发，业务BRD，产品的PRD，设计方案等都是优质资源，但过于分散。

3、询问相关人，产品、测试、前端、研发等，

4、最实在的还是撸代码

而梳理业务分2种场景

一种是线上已存在的产品，需要对其快速熟悉。一种是还未上线的或者准备设计开发的产品，需要对业务方向有更全面的了解。

1.理解业务背景：

通过和产品经理、业务人员的沟通，了解业务的核心目标、业务流程和关键规则。

这个很重要，你仔细观察下身边的同事，他们做完一个需求又一个，但问今年做了啥又说不出来，感觉除了增删改查好像也没别的可说。好像就是实现一个又一个功能，但为什么要这么做说不出来，这么做有什么意义也不清楚。属于无意义输出，像没有附魔的武器，白板装备。

但你把需求背景，价值，ROI等都了解下，为什么这么设计，是否合理，那这项工作会从增删改，上升到业务价值、用户价值、技术价值。如下示例：

业务价值：

审批人也是基于券创建的业务线，动态流转到相关负责人进行审批，业务负责人只须关心各自业务就可以按照以往历史经验可减少损失约10W

用户价值：

通过风控手段减少用户操作失误带来的风险、降低个人失误带来的损失

技术价值：

通过配置手段统一了风控规则，支持风控规则配置化，

简化运维成本配置和维护成本，降低开发维护50%的工作量

审批根据风险等级动态添加审批人降低操作风险，

同时统一升级审批的公共组件，后期同类需求降低开发成本90%，并可快速接入

2.分析功能模块：

将业务按照功能模块进行分类，确定每个模块的主要功能和职责，并理解各个功能模块之前的关系。

把梳理的模块分析后进行分类，可能通过页面划分，相关服务模块划分等方式进行分类。此阶段还是以了解为主，模块划分是否精准还需要通过对代码和业务更进一步了解才能识别。

3.查看代码和文档：

仔细阅读已存在的代码和相关文档，包括需求文档、设计文档、接口文档等。这些文档可以提供对业务逻辑和实现细节的更深入的了解。

对于代码和文档的读取，并分析是十分痛苦的，这个阶段可以识别到不同风格的规范。看公司的要求是否严谨，还有可能没有注释和非常简单的文档描述，甚至是没有相关文档，这个时候需要做好标注，并尝试补全。你在这家公司呆的越久，越能早的享受到这次辛苦的果实。

撸代码方式可以从前往后，即从页面入口一步步往下走，跟到底。也可以从后往前，先了解数据结构表设计等后开始按功能模块进行梳理，都行，没标准，看个人习惯。目标就是你读代码并理解她。

4.绘制流程图：

根据自己的理解和代码分析，绘制业务流程图，将每个功能模块之前的调用关系和数据流动进行详细描述。这样可以更清晰的理解业务的整体架构和流程。

针对代码和文档的理解，同步绘制流程图，可尝试C4或者BPMN（不了解的可看最后的名词解释）等方式绘制，或者自己理解的方式画出来，都可以。但最好在理解后用大家都能看的懂的方式进行绘制。

5.调度和测试：

通过调度和测试线上已存在的功能，检查和验证自己的理解是否准确，并发现可能存在的问题和风险。

代码与流程图都做完，已经对业务有比较清晰的理解了，这个时候需要调度和测试下，最好可以积累下测试用例，方便后期的问题验证。对梳理业务的确认，并能尝试分析是否有风险等。

6.提问和反馈：

如果有任务疑问或者不清楚的地方，及时向相关人员提问并反馈。通过与业务人员和其他开发人员的交流，可以更好的理解业务，并且发现可能的改进和优化点。

对于代码分析和线上验证后还存在问题的，一定找相关人进行提问，这里不要放在那不管，可能是有潜在风险被你发现了，需要紧急处理。如果不是风险，也加深你对业务的理解。这里啰嗦一句，最好是先看资料文档，代码和验证后在去向人提问，不要一上来就凭感觉提问这个不合理，这个不对。你自己想想，别人这么问你，你啥感觉。通过上述方式，自己对业务有一定的了解后大家沟通至少是同频的。

7.学会整理和总结

其实到这步你应该已经总结出些文档流程图了。除非你是最强大脑，过目不忘的大哥。不然还是把之前整理内容总结一下。方便自己忘的时候快速提取出来。我个人比较喜欢脑图（思维导图）。这块也是看个人习惯，能形成个人或者公司的知识库，方便快速查找就行。

尝试分享（选修课）

可以尝试着把自己整理的内容分享出来，如果你害羞可以试试，分享几次也就那么回事了。如果嫌麻烦，就别整。

通过以上步骤，程序员可以快速梳理线上已存在的业务，理解业务架构和流程，并为后续的优化和开发工作提供基础。

名词解释

C4模型：C4模型是一种针对软件架构的层次化系统建模方法。它将软件系统分为四个层次：上下文（Context）、容器（Container）、组件（Component）和代码（Code）。C4模型使用简洁的图形符号和标注，通过层次化的结构来描述软件系统的关键组件和它们之间的关系。C4模型侧重于架构层面的梳理和设计，常用的C4模型工具包括Structurizr、PlantUML等。

BPMN：BPMN（Business Process Model and Notation）是一种用于描述业务流程和工作流程的通用标准。BPMN提供了丰富的符号和标注，可以描述流程中的活动、决策、数据流动等。BPMN不仅可以用于绘制流程图，还可以进行流程分析、模拟和优化等。常用的BPMN工具包括Bizagi、Camunda等。