资料要要全
当你接手一个新项目（别人的项目）的时候，你要第一时间向把项目移交给你的人要到所有的资料。因为在这之后，这个同事可能就会离职了，到时再要什么文档就不太方便了。一般情况下，你需要拿到这些资料：
- 项目代码的地址（svn地址或者是git地址）；
- 系统部署的Linux机器地址，登陆的用户名和密码（方便登陆上去看看机器的运行状况）
- 数据库地址/用户名/密码（不要以为所有项目中都会有用户名密码，有些项目会将用户名密码加密）
- 系统的登陆用户/密码（如果系统有页面，将可以登陆的用户要一个，不用自己再造用户了）
- 其他中间件地址（MQ、Redis等）
- 需求文档
- 接口文档
- 其他所有资料（上面的文档时必须的，如果除此之外还能拿到其他文档，都可以保存下来）
技术栈要看懂
拿到文档资料后，我个人的经验是先要快速浏览下文档，不需要看清文档的每个段落，但是我们要通过略读文档知道这个系统大概是干什么的，有哪些功能。这点对我们后续看代码帮助很大。
熟悉项目技术栈
快速浏览完文档之后，我们就要开始看代码了。这个阶段，你需要能将代码在本地跑起来，知道这个项目运用了哪些技术栈，每个技术栈的作用是什么。
熟悉上下游系统
搞清楚了上下游系统，我们就知道了谁调用了我们系统，或是我们的系统调用了谁，查起问题来也能有的放矢。
知道去哪里查日志
日志是查线上问题的关键，必须要知道怎么查日志，去哪里查日志。
知道怎么打包
接了新需求或者改了Bug之后你肯定要发布吧，那你必须要知道这个怎么打包部署。
知道怎么部署
同上
熟悉业务代码
到了最关键的一步了，但是对于这步我觉得不同的系统我们可以区别对待下。有的系统我们接手过来是要在此基础上长期开发维护的，那这种系统就需要我们好好梳理下业务。
但是有的系统比较稳定了，也不会再加什么新功能，对于这种系统要不要深入研究就需要我们自己权衡了。因为时间成本上可能划不来。
下面是我熟悉业务的一般流程：
-
step1：在看业务代码之前，首先需要看完数据库的表设计，不然会不知所云。
-
step2：然后就是梳理各个接口了，一般是各个Controller（一般系统功能都是通过Controller暴露出去的），如果你能每个接口跟进去debug一遍，整个调用流程都梳理清楚，那么这个业务你就梳理清楚了（这步最好根据接口文档来梳理）
-
step3：当然，系统的功能不都是由Controller提供的，有的是通过定时任务来触发的，所以你要看看系统中配置了哪些定时任务，都实现哪些功能；
-
step4：还有的功能是通过消费MQ触发的，所以也要看看有没MQ相关的交互；
-
step5：类似其他的交互
关于熟悉业务代码这块可能没有太通用的方法，还是需要大家自己总结。