很多新人进入一家新公司后，最头疼的就是如何快速了解公司的业务和项目架构。或者说不要求快速，给你足够的时间，也很难在庞大的业务中整理出思绪。当然，如果你碰到一个特别热心的老员工，事无巨细地给你讲，随时在你身边答疑解惑，那可能还好。但很可惜，我没有碰到这样的人，在加入新公司后，带我的人几乎没有花时间给我讲项目，也没有给我安排一些可以熟悉项目的需求。就这样的一个多月时间里，我慢慢开始靠自己的力量熟悉大概十个项目，并在过程中总结了一些方法，借此机会记录一下，并分享给大家。
这里强调一点，我的策略并不是快速了解一个项目的具体业务，这个不同项目也不一样，无法总结。我的策略是大体了解整个业务线上的所有项目，大概摸清楚每个项目都是干嘛的，他们之间的关系如何，以便以后不论具体负责任何项目不至于找不到方向，具体到细节的业务，虽然需要花时间，但相比对整体上的一头雾水，还是简单许多的。
一. 必要条件我们首先要想的是，有了哪些必要条件后，只要给你足够的时间，你总是能够完全了解整个项目的？这里说的必要条件不是“项目面对的客户是谁”，“项目用的框架是什么”这种，而是真真正正的必要条件，就好比用几条数学公理能推出整个数学体系一样。这里我总结的真正的必要条件只有这两点：
源码位置（gitlab或svn），部署环境（dev/test/online）
所谓项目，其实就是一堆代码放在了一堆机器上而已，所以这些就足够了。当然，为了更加节约时间，最好还要到wiki、jenkins、页面访问路径、数据库地址，我之所以说那两个必要条件，是想说其实项目本质上就是这么简单的一个事，你千万不要想的太复杂。它的业务可以无限复杂，但它的本质却逃不出这些，你千万不可以糊涂。当你无从下手或者什么都不清楚的时候，那么就主要把源码和环境弄清楚吧，其它的都是附属品。
二. 从页面到数据库的线有了上面的必要条件后，我们就开始了解项目了。由于不只是一个项目，所以千万不能深入具体代码，否则你就越来越烦直到放弃，也不会有好的效果。对某个具体项目的了解，一定要建立在对整体了解的基础上。这时我们首先为各个项目画出一条线，并标明每一个节点的信息，就像下面的样子：
页面访问路径--前端项目--后台服务--数据库地址
这里的一个前端项目可能对应多个后台服务，所以最终的图应该差不多是这样：
这个整理的过程，主要是让自己梳理清楚，一共有哪些项目，哪些是前端可视的，哪些是后台提供服务的。并且，大致了解到了前端项目分别调用了哪些后台服务，通过后台服务和数据库的名称，我们能从本质上了解到这条业务线提供了什么功能，从前端项目和页面路径，我们能了解到我们需要给用户展示什么。注意，这个阶段我们只是见名知意，即使点开页面，连接上数据库看看，也千万别花过多的时间，这个阶段的重点就是仅仅知道，这条业务线提的整体内容。
在此基础之上，这个图可以不断细化，比如项目部署的机器，我们可以标注在项目旁边，或者保存在xshell里。此外所有非业务相关的，能查到的尽量都记录下来，这个真的为以后找各种东西方便太多了，否则别看你现在节约了时间，把以后查找相关东西的时间加起来，将会是天文数字了。
这里关于整理项目部署的机器还有个小插曲，跟大家分享一下。由于这部分的信息没人会一个一个地告诉你，就算有也不可能说的特别全。所以我是借助jenkins来整理的。项目部署都需要用到jenkins，只要查看jenkins配置的命令，就可以把部署环境一一整理出来，这个我认为是最全而且最新的。不要和我说查wiki，如果公司wiki都写的这么全，我估计就没这篇文章什么事了。当时我的jenkins权限特别少，只能看一部分项目，而且还只能执行，不能看配置，带我的人也是抠门，每次问他都给我开通所需要的项目的执行权限，多一点都不给。后来我也懒得问了，由于jenkins机器大家都可以用root权限登陆，所以我进入jenkins的配置文件config.xml，给我自己添加了一个admin权限，重启jenkins，再打开之后屏幕满满的项目都出来了，而且都可以查看和修改，畅通无阻。我就这样通过一个个jenkins的配置，整理了部署的机器，也看了下启动的逻辑。
三. 了解项目间的关系这部分如果有老员工愿意和你说说，那最好还是了解一下。如果没有也没关系，先跳过这段，以后慢慢了解也是可以的。
四. 整理数据库表