参考博客：
如果你总是看见代码多就发愁，看见代码脏乱差就诅咒埋怨，看见代码逻辑复杂就头疼，搞不清调用关系就放弃，那你可能永远也变不成代码的主人，只能一次又一次被代码蹂躏。
所以，其实交接代码最重要的事儿，就是：
不要被浩渺如烟并且陌生怪诞的代码吓得不敢动弹，现在就开始读，立刻，马上，坚持十分钟，再坚持十分钟，你就能妙悟真谛。
【注意心态】：不要以追求完美的心态去接手项目，不要试图搞懂整个项目。
千万不要找到对应的控制器方法，一行一行读代码！！！！因为过去的功能已经完成了，需要修改该功能时，你才需要读过去的代码，方便修改。即使遇到不会使用的框架也不要紧，你知道业务逻辑后，可以直接写原生。
要的是结果（老大要功能以最快的速度做出来），以任务为第一。让自己的价值先绽放出来，而不是自己的研究学习能力。否则，会出现，你研究了整个项目的框架结构，熟知了所有的技术要点，却被无情的踢了出来，因为你的价值并没有表现出来
1.项目维护有三宝：沟通 、文档 、代码跑。目标：了解业务逻辑流。
这三点很好理解，初步接手要请教前辈给你点一点业务重点、难点，让自己熟悉下；接着就是看系统的文档了，可以让自己迅速的了解整个项目的方方面面；最后就是走代码，因为前辈的指点可能有误，文档的书写可能有漏，作为一个优秀的程序员只相信自己走的代码，用自己的代码去验证文档，才是最正确的做法。文档只是给了你方向。走代码才能真实的了解具体的业务逻辑
2.重点攻击：数据结构+ER模型。目的：熟知项目的数据结构关系。
其实从事多年的老鸟可以发现，不管是C/S或者B/S，怎样的开发最后都是无非是底层数据库的数据排列筛选好后传递到前台。所以对待一个新的项目，去研究它的数据结构和库表是很有效的。这就要求我们对数据结构这块进行深入研究。
项目出活四部曲，跟、改、理、测要一起。
总结：要不停的试，不停的改
通用步骤：
1、找nginx的配置文件，看看项目放在服务器的哪个地方（由于是接手多个项目，都是以虚拟主机来放的）| 5分钟
2、找对该项目熟悉的产品经理或同事（也包括测试）给你演示一把怎么用，顺便请教下主要功能。 | 30-60分钟
3、小试牛刀：先熟悉软件的前后台各种操作，能体验的都体验一把（尝试修改某个功能，有好多个环境，在本地改）。
4、记录项目中该领域的专业词语，找机会和同事请教，弄懂这个词在这个领域是个什么概念
思路1的具体步骤（从上而下）：
5、打开f12看network找他前后台菜单中对应的控制器（有的请求是在html中用a标签跳转的）。找到每个功能的对应的【增删改查】或每个功能对应的方法名称。如有没见过看不懂的罕见写法，查该版本的手册，切记，统一框架不同版本的同一个方法用法可能都不一致
6、看他每个功能对应的控制器方法中的sql语句的构成
7、通过echo打印原生的sql语句（TP框架，拿sql语句的对象->getLastSql()），看查出来的结果是什么，及通过视图渲染到页面的数据
8、看他的数据库设计，先在心里把表分个类（如 用户的、商品的），然后找外键关系
9、不要看完就了事，看完是记不住的，过俩天也都忘了。在旧项目中新建个控制器，模拟个功能点，模拟人家写的方式，自己写套增删改查操作数据库，展示给页面
思路2的具体步骤（从下而上）：
1、先看公共函数库，传正确和错误的参数，分别测试，看出来的是什么东西。不要看函数中的每一行代码
2、多层继承的话，看他父类，父父类中，大概都有哪些方法，这些方法是做什么的，在心里记个大概
3、看控制器方法中，打印最后的结果，然后看视图层，是怎么展示的
先搞清楚新的系统是搞什么的，就问简单几个问题，谁在用这个系统？用这个系统做什么？然后自己根据这些问题去文档找答案。
弄清楚系统是怎么分层、分模块的，每层、每个模块都用到了什么技术和框架，之间是怎么通信的。有架构设计文档的话学习一下最好，没用过的技术先查查资料知道个大概。
把开发环境搭起来，通过几个典型的功能弄清楚系统里面增删改查、通信、用户交互是怎么实现的。最简单的方法是根据系统的分层，先从前端到数据库把代码疏通一下，搞不清楚的话打开debug模式一步一步走一下。
经过上面三个步骤基本上就可以改几个bug和照葫芦画瓢做个功能了。后面重点关注那些没用过的技术和组件：先搞清它的目的、背景、实现原理和功能列表，再照着文档做几个demo，平常工作时把它的文档建个快捷方式，随手查询学习一下。
平常开发过程中如果遇到问题首先要相信：
1）绝大部分自己遇到的问题很多人已经遇到过并且解决了 。
2）绝大部分自己遇到的问题在当前系统里面已经有了答案。
3）绝大部分自己遇到的问题在你用的框架和组件里面都有现成的解决方案。
对于规模比较大的系统或者系统集合，其实你平时工作接触到的也就是其中的一个系统或者模块，先把自己接触的部分搞定就行了。
对于老系统，首先建议看一下我另外一个回答：在感觉项目代码的构架不行的时候,你们会怎么办? - Jim Jin 的回答
1）老系统其实满是宝藏，里面有很多你可以借鉴和学习的东西。
2）老系统也满是坑，一个看起来毫不悬念的代码改了以后可能会引发地震。
3）很多你看着不爽的代码其实都是有道理的。
4） 不要在老系统里面继续挖坑。
5）看不懂的代码不要动。
6）在你力所能及的范围内让老系统变的更美好。
各位朋友一定要注意：
1、在管理者看来，重构前辈的代码是没什么绩效的，而且风险还大。而救火、在臃肿老代码上不断加东西实现业务需求是有实实在在的绩效的。
2、整天提重构还容易得罪人。你抱怨别人架构垃圾，整天嚷嚷要重构，你可知道，这个架构正是当年某位前辈设计的，这前辈现在是你领导的领导呢。
所以，职场的事情，复杂得很，不可只从技术角度看问题。
参考博客：
作为一个谦卑的初级程序员，刚开始到公司接触大型项目做的工作通常是改改历史遗留问题的bug，写写模块或者组件内部的一些小逻辑以尽快熟悉项目整体架构。有时候一些简单的小问题放到大型项目中，汪洋般的代码量让你无从下手，就算通过开发工具快速找到了目标代码，也不能很快熟悉里面的逻辑到底是怎么一回事儿。经过一段时间的折磨，笔者积累一些自己的方法和技巧。
这些总结可能还不太成熟，但随着时间的积累，对如何快速熟悉大型项目会积累更多的经验，学会更多的技巧。
很想再提醒一下自己，方法很重要，看代码敲代码都要掌握好方法。
加油，永远年轻，永远热泪盈眶！
建议看一下 README.md 文件。一般情况下，项目的创建者都会大致写些东西在里面
cnpm install安装项目依赖（自动根据 package.json 来下载的）（没有 cnpm 自己百度装一下，比 npm 速度快点）
看看 package.json 文件里的 scripts 了解项目通过什么命令启动（cnpm run server/dev）
原文：https://www.cnblogs.com/suwanbin/p/12934019.html