谈谈半路接手项目

最近又半路接手了一个项目。不得不说，每次半路接手项目，都是一场冒险。

每次从搭建环境，到理解系统的架构，到理清上下游的调用，到读懂代码，都要颇费一番苦工。如果运气好的话，有文档，有人交接，还稍微轻松一点；运气不好，没有文档，没人交接，就看造化了。

上班这么多年，半路接手一个项目也经历过好几次了，各种各样的项目都接手过，有人交接、没人交接的都接手过，在这方面也算是比较有经验了。这里就来说说，我自己总结的半路接手项目的经验。

半路接手项目最大的痛苦在于，往往给你的时间很短，却要你在短时间内开始着手项目的开发。别人做到一半的项目，对于你来说却是全新的。一上来，有很多信息要消化。项目的目的是什么，用户是谁，解决什么问题，业务逻辑是怎样的，架构怎么设计的，代码怎么写的，当前做到什么程度，接下来要做什么。一下子这么多信息，要在短时间内消化，确实很痛苦。如果老板限定时间要上新功能，或者有紧急的bug要修，压力就更大了。

我记得刚进现在这家公司的时候，第一天报道，就扔给我一个项目，给我项目的同时，还给了我一堆项目的bug。之前做这个项目的人已经离职，这个项目也没有文档，代码注释也很少。老板给我两个星期时间，让我把那些P1的修掉。鉴于我当时刚接手项目，又是刚进公司，压力还是很大的。不过好在之前已经有过几次半路接手项目的经验，后来上手还是蛮快的。

一般我在接手一个项目的时候，首先会搭建开发环境，把项目在开发环境里运行起来。熟悉一个项目，刚上来，最简单的方式就是成为这个项目的用户，去用这个产品。这个产品的UI长什么样，点击UI的各个button会出现什么样的结果，产品都有些什么功能。一边自己摸索的同时，一边问公司里的同事，特别是这个项目的用户。这样用过几回，自己对产品的功能有个大致的了解，后续开发的过程中也知道该怎么测试项目的功能。

在对项目的功能有个大致的了解后，我会开始解读代码。从项目的运行入口开始，项目包含哪些模块，各个模块之间的调用关系是怎样的，模块中包含哪些关键的函数，这些函数是做什么用。

当然读代码只能了解一个大概，对于函数的输入输出，还是停留在想象。为了更好的理解代码的运行逻辑，我一般读完代码，会开始编写测试案例，把一些重要函数的测试案例都写一遍，并且把这些测试案例都执行一遍。这样下来，基本上我对每个函数的输入输出、怎么调用，都比较清楚了。如果项目当中涉及到一些比较复杂的数据结构，我也会在测试案例中把数据打印出来，看一下数据包含哪些信息，数据在函数之间是怎样传递的。

在做完上面两步后，基本上，我对项目的功能、每个功能背后的代码逻辑，都有个大致的了解了，这时，我会开始开发新的功能，或者修bug，真正上手这个项目。

总的来说，对于半路接手项目，我一般采用这样的方式

第一步，熟悉产品的功能

第二步，编写测试案例

以上是我的个人经验，也欢迎大家在留言里写下自己的心得体会。

（完）

---