进入一家新公司后，最头疼的就是如何快速了解公司的业务和项目架构。
如果碰到一个特别热心的老员工，事无巨细地给你讲，随时在你身边答疑解惑，那可能还好。但很可惜，我没有碰到这样的人，在加入新公司后，带我的人几乎没有花时间给我讲项目，也没有给我安排一些可以熟悉项目的需求。就这样的一个多月时间里，我慢慢开始靠自己的力量熟悉大概十个项目，并在过程中总结了一些方法，借此机会记录一下，并分享给大家。

注意，这里的策略并非快速了解一个项目的具体业务，这个不同项目也不一样，无法总结。
我的策略是大体了解整个业务线上的所有项目，大概摸清楚每个项目都是干嘛的，他们之间的关系如何，以便以后不论具体负责任何项目不至于找不到方向，具体到细节的业务，虽然需要花时间，但相比对整体上的一头雾水，还是简单许多。

1 业务的本质

并非项目面对的客户是谁啊？、项目用的啥框架啊？而是真的能推出所有现存业务的，仅如下两点：

源码位置（如gitlab）
部署环境（dev生产/test测试/online线上环境）

项目，其实就是一堆机器上的一堆代码。为节约时间，最好还有wiki、jenkins、页面访问路径、数据库地址，我之所以说那两个必要条件，是想说其实项目本质上就是这么简单的一个事，你千万不要想的太复杂。
业务再复杂，但本质却逃不出这些，你千万不可以糊涂。当你无从下手或者什么都不清楚的时候，那么就主要把源码和环境弄清楚吧，其它的都是附属品。

2 从页面到数据库的线

有了上面的必要条件后，我们就开始了解项目了。由于不只是一个项目，所以千万不要深入具体代码，否则你就越来越烦直到放弃，也不会有好的效果。

对某个具体项目的了解，一定要建立在对整体了解的基础上。这时我们首先为各个项目画出一条线，并标明每一个节点的信息，就像下面的样子：

页面访问路径–前端项目–后台服务–数据库地址

一个前端项目可能对应多个后台服务，所以最终图差不多这样：

这个整理的过程，主要是让自己梳理清楚，有哪些项目，哪些是前端可视，哪些是后台提供服务。

了解到前端项目分别调用哪些后台服务，通过后台服务和数据库名称，能从本质上了解到这条业务线提供了什么功能，从前端项目和页面路径，我们能了解到我们需要给用户展示什么，即注意输入输出。
注意，这个阶段我们只是见名知意，即使点开页面，连接上数据库看看，也千万别花过多的时间，这个阶段的重点就是仅仅知道，这条业务线提的整体内容。

在此基础上，这个图可以不断细化，比如项目部署的机器，可以标注在项目旁，或保存在xshell。
此外所有非业务相关的，能查到的尽量都记录下来，这个真的为以后找各种东西方便太多了，否则别看你现在节约了时间，把以后查找相关东西的时间加起来，将会是天文数字了。

由于这部分的信息没人会一个一个地告诉你，就算有也不可能说的特别全。所以我是借助jenkins来整理的。项目部署都需要用到jenkins，只要查看jenkins配置的命令，就可以把部署环境一一整理出来，这个我认为是最全而且最新的。不要和我说查wiki，如果公司wiki都写的这么全，我估计就没这篇文章什么事了。当时我的jenkins权限特别少，只能看一部分项目，而且还只能执行，不能看配置，带我的人也是抠门，每次问他都给我开通所需要的项目的执行权限，多一点都不给。后来我也懒得问了，由于jenkins机器大家都可以用root权限登陆，所以我进入jenkins的配置文件config.xml，给我自己添加了一个admin权限，重启jenkins，再打开之后屏幕满满的项目都出来了，而且都可以查看和修改，畅通无阻。我就这样通过一个个jenkins的配置，整理了部署的机器，也看了下启动的逻辑。

3 了解项目间的关系

这部分如果有老员工愿意和你说说，那最好还是了解一下。如果没有也没关系，先跳过这段，以后慢慢了解也是可以的。

4 整理数据库表

上面都是整理项目的大体框架，还没有涉及到具体的项目细节。这一部分，仍然不去涉及。如果说站在整个业务的本质上看，业务无非就是一堆代码运行在一堆机器上。那么站在单个项目来看，一个项目无非就是对数据库的增删改查操作而已，或者从使用者的角度看，一个项目就是输入一些参数得到一些返回结果。所以接下来我们要做两件事，一个是整理数据库表，一个是整理Controller层的所有接口。

这里首先要选择一个核心项目去看，众多项目中一定有一个是核心项目，先从这个开始看起。

如果数据库的表比较少，那我们拿工具导出来表结构，一个个看就行了，这个不难。但如果数据库表特别多，我们首先要将表名全部导出，筛选出那些核心的表。这里导出表名、筛选表以及后面的分析表字段，不妨给自己做个工具，我在遇到一些很麻烦的或者感觉以后还可以通用的事情时，就会做成一个小工具，放在一个我给自己起名为javamate的程序中，这些小工具逐渐积累起来你会发现今后有意想不到的方便。

话说回来，如何判断哪些是核心表呢，不要着急，我们首先排除掉一些没用的。拿我在公司分析的系统来说，一共150多个表，其中有好多copy结尾的是备份，flow结尾的是流水，rel结尾的是中间关联表，statistics结尾的是数据统计表，log结尾的是日志表，config结尾的是配置表。等等。排除掉这些对核心业务理解无影响的表之后，所剩的也就20来张表，再根据他们的名字，可以看出好多表是属于一类的，比如order表就有各种order，按类别再分出来也就四五类，再分析起来就不难了。当然如果是更大的体系结构，那就要再不断做拆解。

再具体分析这些核心表字段之前，还要做一件事就是找出表中间的关系。如果表b中有个字段叫比如a.id，那么b和a就是一对多的关系，如果两个表有rel中间表，那二者就是多对多的关系，起码从逻辑上讲是这样的。这个分析过程我也是做了个小工具，通过程序来判断的。

到此，你就对整体的数据库结构有所了解了。根据表名也能对表的大致内容有所了解，接下来就是针对具体的表，看里面具体的字段和前人给出的备注，这个过程就没有技巧了，要耐心，要慢慢熬。

5 深入代码层

当你对数据库表做了以上到了解后，你基本上对这个系统能提供什么服务了解到差不多了。这个不论你的代码长什么样子，数据库摆在那里，其实能提供的服务就已经差不多出来了，对于有经验的人来讲，代码的业务逻辑也大致能猜到个八九分。

我认为一个业务相关的项目代码只分三个部分：

1. 通过交互对自身数据库进行增删改查操作

2. 通过定时任务或服务器脚本对自身数据库进行增删改查操作

3. 调用或通知其他服务做一些事情

如果只是单一项目，无非就是通过各种途径去玩自己的数据库而已，前两点足够了。而如果是微服务部署，那么加一个第三点足矣。我们将代码逻辑分成这三个部分看，快速了解一个项目就不成问题，甚至在你没有看过某一项目而突然有一个bug要你解决时，你也可以按照这种方式去快速定问问题。

通过交互对自身数据库进行增删改查操作：这个无非是最简单的一部分，即使复杂也是代码较长，表较多而已。所谓的交互，或许是Controller暴露给前端用户的接口，或许是开一个rpc端口暴露给其他微服务的接口，总之是第三方去触发的。这里我也给自己做了个小工具，扫描出所有的暴露服务的接口，展示出方法名，路径名，参数列表和返回值等。和数据库一样，如果接口很少那么一个个看，如果特别多，还是先找出比较核心的几个方法研究。这里我用的是postman，把要研究的接口访问保存起来，并且添加访问成功和失败的Example。这里我推荐自己开发的时候也把postman用起来，越详细越好，postman不只是可以简简单单访问你的接口，还能做批量测试，还可以生成api文档用于和前端交互。这样你不但测试了自己的接口，还省的写文档了。而且postman还有个好处就是可以给自己的接口mock一个服务，这样即使你的接口挂了，或者你的接口根本就没写好，你可以让前端人员先访问你的mock，完全不影响前端边测试边开发，这才是真正的前后端分离嘛。整理出所有接口后，肯定大部分是很简单的，一看就懂，一层一层点进去直到数据库层的sql语句，该接口最本质的东西就出来了。如果是复杂的，那就一步一步debug，花时间总是可以分析的。如果再复杂的，你可以画流程图（这里我比较推荐用processon）。甚至几个接口围绕一个功能的，你可以画状态流转图。比如我之前看我们公司处理订单业务这块，逻辑确实比较复杂，我就画了类似如下的具有程序员视角的状态流转图（这里只是示例图）：

状态流转图：横轴代表order_status字段的状态，纵轴代表当order_status是以上状态时，触发该接口操作会使该字段发生什么变化）

订单表 order_status 状态流转
0-待支付 1-已支付 2-已取消 3-退款中 4-已退款 5-退款失败
支付成功异步通知来了 -->1 报错报错报错报错报错
用户发起退款报错 -->3 报错报错报错报错
退款成功异步通知来了报错报错报错 -->4 报错报错
退款失败异步通知来了报错报错报错 -->4 报错报错
　　接口对表的影响图：这里你可以把所有涉及到的表以及表中的关键字段列举出来，然后看分别调用接口后对各个表字段的影响，变化的就用红色标出

有了这两种维度的视角，我相信再复杂的业务都能很理清楚，也能发现某些bug最本质的问题。我正是通过这样的方式，把一个本来不属于我的项目短时间内了解清楚，快速准确地修复了好多顽固的bug。虽然项目很烂，业务逻辑十分混乱，但正是这样一段时间锻炼了我深入代码理清逻辑的能力，也有了自己独特的一套方法。

通过定时任务或服务器脚本对自身数据库进行增删改查操作：这个和第一种类型一样，只不过换了个入口。如果有些问题你发现并不是交互而产生的，那你就要寻找其他入口。比如定时任务，或者启动的时候就开启的一些线程。寻找这些入口的确不是特别容易，比较头疼，但也只是入口比较隐蔽而已。找到他，记下来，具体分析过程还是按照上述方法去分析，就可以了。

调用或通知其他服务做一些事情：上述两种代码如果你都摸得差不多了，整个项目对自身的玩法基本你已经摸透了，那还剩一小部分就是它和其他服务之间的交互。代码中一定有通过mq给其他服务发消息，或者直接调用其他服务的接口，或者调用类似云推送的接口让它去帮忙像mq发消息。总之不管形式如何，都只是为了rpc其他服务而已。这部分代码可能更加隐蔽，但数量少，逻辑也简单，你需要做的仍然只是找到它们。这部分也是为了解项目之间的关系打下伏笔。

这三种类型的代码研究清楚后，对于一个业务型的项目来说，已经基本足够了。对于一些基础服务和中间件类型的服务，还是得慢慢积累技术深度才行，了解过程仍然也是可以有规律的，只不过需要更底层的方式去分类，比如将代码分成资源的加载，模式的匹配，等等。由于本篇文章是快速了解一个业务型的项目，所以就不展开叙述了。

6 重新理清项目间的关系

好了，这时候每个项目你已经大致了解，最起码调用的效果，数据库所能提供的服务，甚至某些关键部分的本质逻辑，你是清楚的。这个时候，要重新整理下项目之间的关系。

根据之前的接口名称，详细了解下项目间的调用关系。理不清的部分去问老员工，这时候你带着自己的了解问，他们也能给出更多的信息。
看看每个项目中用到的中间件，主要是mq服务，看看谁是生产者，谁是消费者，以此来了解关系
这时你应该已经开了好几轮的周会了，接下来的周会你应该能听懂部分内容。根据每个人的描述和最新的几组需求，逐渐摸清楚现在项目面临的问题，以及哪个项目是核心，哪个项目是辅助，哪个项目是以稳定安全为主的

到此为止，整条业务线你就有了大致的了解，接下来就要结合你具体负责的内容，领导安排你做的方向，去看具体的业务代码了。深入其中，事无巨细地了解。但此时，你通过前面的努力，你已经可以站在一定的高度看每一个项目了，虽然你细节上还是不了解，但这是完全不同的。在研究具体业务代码的同时，不断地跳出来看整条业务线的框架，修正之前由于不了解具体业务而理解错误的架构。长此以往，你一定会在某个项目中脱颖而出，让大家认识到你的全局视野，这也是走出老是写增删改查代码怪圈的一个途径。慢慢会有人意识到，你对项目的理解总能站在全局的视野，很多需要跨项目去做的业务，也会自然而然想到你，慢慢地，你会接触到更为核心的东西，成为架构师，或者去转向产品，转向管理。

参考

https://www.cnblogs.com/flashsun/p/9450066.html

研发新人如何快速熟悉新项目和业务相关推荐

程序员快速熟悉新项目和业务逻辑的技巧
很多新人进入一家新公司后或进入一个新的项目组,最头疼的就是如何快速了解公司的业务和项目架构,或者说不要求快速,即便有足够的时间,也很难在庞大的业务中整理出思绪.当然,如果你碰到一个特别热心的老员工,事 ...
新人如何快速上手新项目？
按楼主的经验和知识,本文总结了应用开发中的各种存储架构,从易到难,从起步到起飞.如有不对之处,欢迎留言. 1.单库最简单的初始架构,适用于千万级以下的数据,并发量低的场景. 单库.单表或单库.多个 ...
推荐必读：测试人员如何快速熟悉新业务？
身处职场,学习新业务在所难免,尤其是测试人员,具备良好的业务知识是我们做好质量保障的前提,不管是职场「新人」还是「老人」,快速熟悉业务的能力都是不可或缺的,这是我们安身立命的根本. 但,这样的能力并不 ...
测试员入职新公司如何快速熟悉新业务？
身处职场,学习新业务在所难免,尤其是测试人员,具备良好的业务知识是我们做好质量保障的前提,不管是职场「新人」还是「老人」,快速熟悉业务的能力都是不可或缺的,这是我们安身立命的根本. 但,这样的能力并不 ...
如何快速上手新项目？
如何快速上手新项目? 我觉得可以遵循以下几个步骤: 1. 获取项目相关信息进入一家新公司后,如果遇到不负责任的同事呢,可能直接甩给你项目地址,然后就让你自己研究了.这就好比产品经理直接甩给你一个需求 ...
项目经理怎么在两周内熟悉一个项目的业务?
项目经理空降到一个进行中的项目,怎么在两周内熟悉一个项目的业务? 四步帮你解决:明确项目业务目标,了解系统功能模块,弄清系统核心业务流程,多使用系统. 一.明确项目业务目标明确项目业务目标,也就是了 ...
没有文档，没有老员工讲解，悲催的新人如何快速熟悉一个新项目？
本文来自闪客Sun的投稿,博客地址: https://www.cnblogs.com/flashsun/p/9450066.html 看完你就会明白,虽然有一定的方法论,但是不下功夫,没有耐心,还是万 ...
分享：新入职时，如何快速熟悉一个项目的代码
一.总体思路昨晚是深夜撰文的阿菌,希望通过这篇文章和大家分享一下,初入职场时,如何才能快速地熟悉一个项目的代码. 说实话,感觉自己去年入职时上手项目的速度是比较慢的,可能是没有一些系统的方法论参考吧 ...
如何快速接手并熟悉新项目
论文档的重要性新项目,基本是之前完全没参与过的,我多么希望有<<xx项目说明文档>>,<<xx项目部署文档>>,<<xx项目历史记录文档& ...

研发新人如何快速熟悉新项目和业务