开发解惑系列:三:极快理解项目的业务流程

最近发现一些年轻的小伙伴不太清楚如何快速理解项目的业务流程，比如入职快半个月了，对项目的业务流程还是模模糊糊的，也没有文档，这里分享下个人的经验和想法：

一、技术方面：

1、首先需要知道当前项目的技术栈/依赖组件是哪些？以及大概的物理部署架构图大概会是什么样子（即使没定，自己也要猜一下），然后包括去梳理数据库表、中间件、服务个数、模块个数。 然后要先看pom.xml中依赖了哪些jar包，每个jar包的含义自己要弄清楚，这样可以大概知道项目都用到哪些，根据jar包是可以猜测出会有哪些功能的

2、要自己尽快写出第一个超简单的CRUD，比如学生管理，根据公司的框架尽快写出一个

3、1-2完成后，启动项目，找到你感兴趣的一个功能点，根据前端的点击，找到对于的controller，分析下某个模块的CRUD流程。

二、业务方面

一般新员工都会是这样，但是要扪心自问问自己，下班后是否继续分析和学习当前公司的项目了，对于新环境，不能着急，要花下班的时间进行分析学习。

三、主动与积累方面

好多公司就是没有文档的，那么谁来当第一个人谁就容易更快获得信任，比如今天开发了A模块，那你开发完成后，就把这个模块的基本业务流程、涉及的表、几个接口梳理成1个文档，当哪里有变化就随时更新自己的文档，形成一定的量以后(5篇 )，你就是你们团队的大神。

同时建议你在你公司的电脑上，安装Confluence这种企业Wiki工具，把自己负责的东西写上去，当领导觉得来找你对需求时，你就在网页上给他看这个文档，边说边介绍，领导一看这个小伙子工作方式很不错啊，就得推广下你的工作方式了，你就NB了，新环境前期多少自己要该装的装一下，被动触发团队工作模式。

这个方面很重要，比如项目用了一个seata，那就写个项目是怎么集成的等等。

自己主动梳理文档很重要，就是要在某一天让项目组的人震惊、羡慕。

四、需求确认方面

一般经验尚少的员工缺乏主动分析业务需求的能力，领导说的需求自己以为理解，其实没有根据自己想法和业内的实现进行分析，并说出优缺点，也会导致需求不对或自己感觉慌，比如领导给你需求后，你就先画流程图，然后找领导确认，领导心里会慢慢认可你的做事方式的，不主动展示自己的工作方式很容易不被信任。

如果对你有帮助，请点赞吧

这篇好文章是转载于：学新通技术网