引子
上山多了总遇虎，工作久了总能送走几位老同事，然后继承他们的遗志，接手他们的项目。如果你们原本在同一个项目组还好，最怕的是这个项目是你们的唯一交集，这就真的是初见乍欢，久处仍怦然呀。不过作为万能的码农，领导问：“多久能接手？”，我们仍会毫不犹豫的说：“一个月，保证完成任务”，如果领导皱皱眉头，“其实加加班，两个星期也可以”。
问题
我们应该如何快速接手一个陌生的项目呢？
方案
我们的项目由两部分构成，业务+代码。之所以把业务放在代码前面，没错，我们需要首先理解现行的业务，只有理解了业务，才能知道我们现在做的对不对，包括我们代码的实现和后续问题处理方式的正确性。
业务包含两部分，自己系统本身的业务和上下游相关系统业务。对于本身系统业务，产品和运营是最好的助力，他们可以帮忙你快速把握业务的核心。不过这两者又有不一样的地方，产品可以总结出来各个业务场景的具体的实现，运营可以告知他们每日的工作以及关心的核心点。对于刚刚接手系统，清楚理解重点显然是最主要的。
对于上下游相关系统业务，初期我们只需要理解他们是干什么的，以及系统间是如何交互即可。比较建议梳理出来相关系统间的输入和输出内容，这样子将有助于提高你对于系统的把控度。
代码，在进入代码海洋前，我们要做的第一件事，是向佛祖祈祷前任是一个仁慈的人，因为仁慈能产生智慧，智慧可以让他写出仁慈的代码。不过在实际中，接手一个旧的项目，旧代码其实并不那么重要，我们之所以需要看旧代码，是因为我们需要维护旧的系统功能。但是经过前面的业务梳理，其实你已经可以知道，整个系统核心的功能是哪几个，从而实际需要深入理解的代码并不多。
对于如何接手一个项目的问题，以上所述是否是最重要的点呢？是也不是！对于一个系统，我们的最基础的要求是正常运行。任何系统每天都会有可能出现莫名其妙的问题，而这些问题，对于一个老系统而言，显然都不会是第一次出现，问题的处理也显然有着固定的模式，所以在工作交接中，应要求前任留下日常问题处理方案。至于如何让前任就范，就是八仙过海了。
经过以上一系列操作，相信两个星期基本掌控一个系统没有太大难度。至于后续的完全融入项目，就需要业务需求的推动了，只有在需求中反复锤炼，才能达到人与系统的天人合一境界。
by 江沛