>[danger]【注意心态】：不要以追求完美的心态去接手项目，不要试图搞懂整个项目。 千万不要找到对应的控制器方法，一行一行读代码！！！！<span style="color:red;">因为过去的功能已经完成了，需要修改该功能时，你才需要读过去的代码，方便修改</span>。即使遇到不会使用的框架也不要紧，你知道业务逻辑后，可以直接写原生。 &nbsp; 要的是结果（老大要功能以最快的速度做出来），<span style="color:red;">以任务为第一。让自己的价值先绽放出来</span>，而不是自己的研究学习能力。否则，会出现，你研究了整个项目的框架结构，熟知了所有的技术要点，却被无情的踢了出来，因为你的价值并没有表现出来。先站稳，再向上爬。必须对即将进行的阶段学习有个预估 # :-: 代码看不懂怎么办 如果你总是看见代码多就发愁，看见代码脏乱差就诅咒埋怨，看见代码逻辑复杂就头疼，搞不清调用关系就放弃，那你可能永远也变不成代码的主人，只能一次又一次被代码蹂躏。 所以，其实交接代码最重要的事儿，就是： 不要被浩渺如烟并且陌生怪诞的代码吓得不敢动弹，现在就开始读，立刻，马上，坚持十分钟，再坚持十分钟，你就能妙悟真谛。  # :-: 接手方法：不变应万变 1.项目维护有三宝：沟通 、文档 、代码跑。目标：了解业务逻辑流。 这三点很好理解，<span style="color:red;">初步接手要请教前辈给你点一点业务重点、难点，让自己熟悉下</span>；接着就是看系统的文档了，可以让自己迅速的了解整个项目的方方面面；最后就是走代码，因为前辈的指点可能有误，文档的书写可能有漏，作为一个优秀的程序员只相信自己走的代码，用自己的代码去验证文档，才是最正确的做法。文档只是给了你方向。走代码才能真实的了解具体的业务逻辑 2.重点攻击：数据结构+ER模型。目的：熟知项目的数据结构关系。 其实从事多年的老鸟可以发现，不管是C/S或者B/S，怎样的开发<span style="color:red;">最后都是无非是底层数据库的数据排列筛选好后传递到前台</span>。所以对待一个新的项目，去研究它的数据结构和库表是很有效的。这就要求我们对数据结构这块进行深入研究。 项目出活四部曲，跟、改、理、测要一起。 1. 跟：抓住一个功能点，深入的调试跟踪流程，分析代码直到弄明白为止。 2. 改：修改源代码，编译运行，看修改前后有什么变化，这是感知代码用途的最佳途径。 3. 理：尝试弄清整个项目的业务逻辑 4. 测：熟悉业务逻辑后，清库测试，测验是否符合自己所想。