如何快速熟悉一个新项目

进入一家新公司后，最头疼的就是如何快速了解公司的业务和项目架构。

 

由于文档不多，没有文档，或者是文档严重落伍， 根本无法看；若是你碰到一个特别热心的老员工，事无巨细地给你讲，随时在你身边答疑解惑， 那简直是天大的好运气， 现实是你们都很忙，没人给你讲解。

 

很快就要深刻项目作开发了，怎么办呢？

 

我在加入新公司后，就遇到了悲催的状况。可是在一个多月时间里，我靠本身的力量熟悉了大概十个项目，总结了一些方法，分享给你们。

 

这里强调一点，个人策略是大致了解整个业务线上的全部项目，大概摸清楚每一个项目都是干吗的，他们之间的关系如何，以便之后具体项目时不至于找不到方向，具体到细节的业务，固然还须要花时间，但相比对总体上的一头雾水，仍是简单许多的。

 

一. 必要条件

 

这里说的必要条件不是“项目面对的客户是谁”，“项目用的框架是什么”这种，而是真真正正的必要条件，就比如用几条数学公理能推出整个数学体系同样。这里我总结的真正的必要条件只有这两点：

 

源码位置（gitlab或svn）

 

部署环境（dev/test/online）

 

所谓项目，其实就是一堆代码放在了一堆机器上而已，因此这些就足够了。固然，为了更加节约时间，也要得到wiki、jenkins、页面访问路径、数据库地址等相关信息。

 

我之因此说那两个必要条件，是想说其实项目本质上就是这么简单的一个事，你千万不要想的太复杂。

 

它的业务能够无限复杂，但它的本质却逃不出这些，你千万不能够糊涂。当你无从下手或者什么都不清楚的时候，那么就主要把源码和环境弄清楚吧，其它的都是附属品。

 

二. 从页面到数据库

 

有了上面的必要条件后，咱们就开始了解项目了。因为不仅是一个项目，因此千万不能深刻具体代码，不然你就愈来愈烦，怀疑人生，很快放弃。

 

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

 

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

 

这里的一个前端项目可能对应多个后台服务，因此最终的图应该差很少是这样：

 

 

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

 

了解前端项目分别调用了哪些后台服务，经过后台服务和数据库的名称，咱们能从本质上了解到这条业务线提供了什么功能，从前端项目和页面路径，咱们能了解到咱们须要给用户展现什么。

 

注意，这个阶段咱们只是见名知意，即便点开页面，链接上数据库看看，也千万别花过多的时间，这个阶段的重点就是仅仅知道，这条业务线提的总体内容。

 

在此基础之上，这个图能够不断细化，好比项目部署的机器，咱们能够标注在项目旁边，或者保存在xshell里。此外全部非业务相关的，能查到的尽可能都记录下来，这个真的为之后找各类东西方便太多了，不然别看你如今节约了时间，把之后查找相关东西的时间加起来，将会是天文数字了。

 

这里关于整理项目部署的机器还有个小插曲，跟你们分享一下。因为这部分的信息没人会一个一个地告诉你，就算有也不可能说的特别全。因此我是借助jenkins来整理的。项目部署都须要用到jenkins，只要查看jenkins配置的命令，就能够把部署环境一一整理出来，这个我认为是最全并且最新的。

 

不要和我说查wiki，若是公司wiki都写的这么全，我估计就没这篇文章什么事了。当时个人jenkins权限特别少，只能看一部分项目，后来费了很大的劲，想了不少办法才看到项目的配置，整理出了部署的机器。

 

三. 了解项目间的关系

 

这部分若是有老员工愿意和你说说，那最好仍是了解一下。若是没有也不要紧，先跳过这段，之后慢慢了解也是能够的。

 

四. 整理数据库表

 

咱们上面都是整理项目的大致框架，尚未涉及到具体的项目细节。这一部分，仍然不去涉及。

 

若是说站在整个业务的本质上看，业务无非就是一堆代码运行在一堆机器上。那么站在单个项目来看，一个项目无非就是对数据库的增删改查操做而已，或者从使用者的角度看，一个项目就是输入一些参数获得一些返回结果。

 

因此接下来咱们要作两件事，一个是整理数据库表，一个是整理Controller层的全部接口。

 

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

 

若是数据库的表比较少，那咱们拿工具导出来表结构，一个个看就好了，这个不难。但若是数据库表特别多，咱们首先要将表名所有导出，筛选出那些核心的表。

 

这里导出表名、筛选表以及后面的分析表字段，不妨给本身作个工具，我在遇到一些很麻烦的或者感受之后还能够通用的事情时，就会作成一个小工具，放在一个我给本身起名为javamate的程序中，这些小工具逐渐积累起来你会发现从此有意想不到的方便。

 

话说回来，如何判断哪些是核心表呢，不要着急，咱们首先排除掉一些没用的。拿我在公司分析的系统来讲，一共150多个表，其中有好多copy结尾的是备份，flow结尾的是流水，rel结尾的是中间关联表，statistics结尾的是数据统计表，log结尾的是日志表，config结尾的是配置表。等等。

 

排除掉这些对核心业务理解无影响的表以后，所剩的也就20来张表，再根据他们的名字，能够看出好多表是属于一类的，好比order表就有各类order，按类别再分出来也就四五类，再分析起来就不难了。固然若是是更大的体系结构，那就要再不断作拆解。

 

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

 

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

 

五. 深刻代码层

 

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

 

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

 

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

 

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

 

3. 调用或通知其余服务作一些事情

 

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

 

经过交互对自身数据库进行增删改查操做

 

这个无非是最简单的一部分，即便复杂也是代码较长，表较多而已。所谓的交互，或许是Controller暴露给前端用户的接口，或许是开一个rpc端口暴露给其余微服务的接口，总之是第三方去触发的。

 

这里我也给本身作了个小工具，扫描出全部的暴露服务的接口，展现出方法名，路径名，参数列表和返回值等。

 

和数据库同样，若是接口不多那么一个个看，若是特别多，仍是先找出比较核心的几个方法研究。这里我用的是postman，把要研究的接口访问保存起来，而且添加访问成功和失败的Example。

 

这里我推荐本身开发的时候也把postman用起来，越详细越好，postman不仅是能够简简单单访问你的接口，还能作批量测试，还能够生成api文档用于和前端交互。这样你不但测试了本身的接口，还省的写文档了。并且postman还有个好处就是能够给本身的接口mock一个服务，这样即便你的接口挂了，或者你的接口根本就没写好，你可让前端人员先访问你的mock，彻底不影响前端边测试边开发，这才是真正的先后端分离嘛。

 

整理出全部接口后，确定大部分是很简单的，一看就懂，一层一层点进去直到数据库层的sql语句，该接口最本质的东西就出来了。

 

若是是复杂的，那就一步一步debug，花时间老是能够分析的。若是再复杂的，你能够画流程图（这里我比较推荐用processon）。甚至几个接口围绕一个功能的，你能够画状态流转图。好比我以前看咱们公司处理订单业务这块，逻辑确实比较复杂，我就画了相似以下的图：

 

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

 

 

接口对表的影响图：这里你能够把全部涉及到的表以及表中的关键字段列举出来，而后看分别调用接口后对各个表字段的影响，变化的就用红色标出

 

有了这两种维度的视角，我相信再复杂的业务都能很理清楚，也能发现某些bug最本质的问题。

 

我正是经过这样的方式，把一个原本不属于个人项目短期内了解清楚，快速准确地修复了好多顽固的bug。

 

虽然项目很烂，业务逻辑十分混乱，但正是这样一段时间锻炼了我深刻代码理清逻辑的能力，也有了本身独特的一套方法。

 

定时任务或服务器脚本

 

这个和第一种类型同样，只不过换了个入口。好比定时任务，或者启动的时候就开启的一些线程。

 

寻找这些入口的确不是特别容易，比较头疼，但也只是入口比较隐蔽而已。找到他，记下来，具体分析过程仍是按照上述方法去分析，就能够了。

 

调用或通知其余服务作一些事情

 

代码中可能有经过mq给其余服务发消息，或者直接调用其余服务的接口，或者调用相似云推送的接口让它去帮忙像mq发消息。

 

这部分代码可能更加隐蔽，但数量少，逻辑也简单，你须要作的仍然只是找到它们。这部分也是为了解项目之间的关系打下伏笔。

 

这三种类型的代码研究清楚后，对于一个业务型的项目来讲，已经基本足够了。

 

对于一些基础服务和中间件类型的服务，仍是得慢慢积累技术深度才行。因为本篇文章是快速了解一个业务型的项目，因此就不展开叙述了。

 

六. 从新理清项目间的关系

 

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

 

1. 根据以前的接口名称，详细了解下项目间的调用关系。理不清的部分去问老员工，这时候你带着本身的了解问，他们也能给出更多的信息。

 

2. 看看每一个项目中用到的中间件，主要是mq服务，看看谁是生产者，谁是消费者，以此来了解关系

 

3. 这时你应该已经开了好几轮的周会了，接下来的周会你应该能听懂部份内容。根据每一个人的描述和最新的几组需求，逐渐摸清楚如今项目面临的问题，以及哪一个项目是核心，哪一个项目是辅助，哪一个项目是以稳定安全为主的

 

到此为止，整条业务线你就有了大体的了解，接下来就要结合你具体负责的内容，领导安排你作的方向，去看具体的业务代码了。深刻其中，事无巨细地了解。

 

但此时，你经过前面的努力，你已经能够站在必定的高度看每个项目了，虽然你细节上仍是不了解，但这是彻底不一样的。

 

在研究具体业务代码的同时，不断地跳出来看整条业务线的框架，修正以前因为不了解具体业务而理解错误的架构。久而久之，你必定会在某个项目中脱颖而出，让你们认识到你的全局视野，这也是走出总是写增删改查代码怪圈的一个途径。

 

慢慢会有人意识到，你对项目的理解总能站在全局的视野，不少须要跨项目去作的业务，也会天然而然想到你，慢慢地，你会接触到更为核心的东西，成为架构师，或者去转向产品，转向管理。