如何快速接手一个项目

场景

不知道在工作中你有没有遇到要接手别人系统或者项目的情况，比如说你的同事离职了，他负责的业务转交给你，或者是你刚到一个公司，需要熟悉新的系统，亦或是你想要更好地与别人合作，想对别人负责的业务有所了解。了解新的东西，并承担相应的责任都能够让我们走出自己的舒适圈，拓宽自己的经验，提升自己的能力。可很多时候，面对一个大的系统，我们总感觉有点无从下手的，觉得这里面很多东西都是自己没接触过的，光了解一些原理和概念就够费劲的了，更别说接手维护了。

就拿我自己来说，我刚来现在这家公司时就被要求接手一个搜索系统，我之前没做过搜索系统，光了解整体的框架就费了好几个月，后面来来回回做了几个相关项目后对它还是一知半解，弄了一年多才搞清楚整个系统是怎么一回事。现在回过头去看，我其实做了很多无用功，如果当时我运用的方法得当，我可能只需要几个月的时间就能对该系统有个整体性的了解。这里面其实没有什么奇技淫巧，完全是自己的心态和做事的原则，这些东西不仅适用于软件开发，也适用于其他行业。

心态

做任何事情都需要一个良好的心态，我想不必多重复了，但这里我想说的是，在做任何事之前，我们 不要因自己不熟悉的事物而产生压力，更不要觉得它很难做好。我们每天都会接触到自己不熟悉的东西，从不熟悉到熟悉是学习和成长的必经之路，如果每天都干着自己熟悉得不能再熟悉的事情，那么自己不是在重复做事情吗？自己能从中获得多少经验？技能又能提升多少呢？另外，一件事情的难或易只有在你去做了之后才会知道，提前做预设不仅会打击自己的信心，搞不好还会让自己陷入焦虑。想想看，既然别人肯把这个事情交给你，说明别人至少是认可你的能力的，也是对你充满信任的，所以我们自己也要这么看自己才对。

关于心态，容我再啰嗦几句。心态这个东西并不是说说就可以提升的，还需要在事上练。比如说，debug 就是一个很锻炼心态的事情，《程序员修炼之道》 中说到 “不要紧张” 是 debug 的第一原则，很多人会觉得，这还不简单，调试个程序有啥可紧张的。的确，如果调试的是一个你自己的学习项目，那确实没啥好紧张的，因为你找不找的出问题，以及什么时候找出问题都不会有啥影响。但假如说你的调试的成功与否，速度快慢都会直接影响到公司产品的正常运作以及公司的营收、声誉等等，那么你还会不紧张吗？回想自己第一次参加工作后的线上 debug，我那时紧张得手抖得不行，手心、全身冒汗，脑子里就想着一件事情，不管用什么方法，赶紧把这个问题解决了，后来是解决了，但是这个经历终身难忘。所以，想要不紧张，还得让自己多紧张几次，特别是那种大场面，多经历几次，见的多了，下次自然就不紧张了。

另外，我们要搞清楚一个事实，不管是 debug 还是其他的线上问题排查，我们的最终目的都是解决问题，而不是责怪谁谁谁。一个系统出了问题，并不是某个人的错，是整个流程存在不足。因此，我们大可以把 debug 当作是做不出来没事，做出来有奖励的事情，这没啥可紧张的。

先整体再局部

很多人在做一件事情之前，都会想着去学某些东西，比如在接手搜索系统之前，要把相关的技术，比如 ElasticSearch，Solr 弄懂，在接手一个 Go 项目前，要把 Go 的各种语法，以及项目中用的各种包都给看一遍，在接手一个前端项目前，要把其用的框架给摸透。有着这样的想法，我们很难做到 快速 接手。

当然，我并不是反对学习相关技术，我只是觉得这个先后次序需要调整。我自己之前也是抱着类似的思想——要想做 X，必须先学懂 Y。现在看来这浪费了我大量的时间不说，该学的没学到，该做的也没做好。要知道，一个成熟并被广泛应用的技术大都是包罗万象的，它里面充斥着诸多的细节和功能。举个不是很恰当的例子，假如说一门技术有 100 个功能，而你要做的项目可能只用到其中的一、两个功能，你不先看项目，直接跑去学这门技术，你面对的是这 100 个功能，这不是给自己出难题是什么？而且如果学习不结合实际的应用场景，学得快，忘得也快，等到你做项目时，你发现你学的大部分都用不着，用得上的自己也掌握的不是很牢，感觉时间白花了。经历过的都知道，这非常让人沮丧。

面对一个项目中用到的技术，正确打开方式是，先了解 这门技术是做什么的？它是为了解决什么样的问题？主要应用在什么样的场景？和类似的技术相比，它有着哪些特性和优势？总之，不需要深入到细节，只需要整体了解下该技术即可，还有，如果可以的话，大致浏览一遍这门技术的官方文档，了解下这门技术的核心功能，以及相关接口，真正用到了也知道到哪去找答案。做到这些，其实花不了自己几天的时间，但有了这些就足够我们开始了解项目了。

看具体项目的时候，我们依然遵循先整体再局部的方法。假设你要接手一个系统，首先第一件事要弄清楚这个系统是做什么的？它的输入是什么？对应的输出又是什么？相信这几个问题的答案应该不难回答，知道了之后，你可以假定一个请求（输入），然后看看这个请求一步步经过了这个系统的哪些模块，这些模块是如何构建并影响最后的输出的。另外，除了产生最后的输出，还产生了哪些变化，比如是否触发了其他系统的请求？是否产生了数据？是否会对系统状态造成改变？等等。

有了这些了解，我们就可以画出流程图了，类似下面这样：

这个图只是一个例子，你不需要知道它是什么，你也不需要参考它的格式。因为图是画给自己看的，不是别人。你可以用自己喜欢的工具，按照自己喜欢的方式来画图，只要能够帮助你把整个系统的内部流程串起来，各个模块之间的关系捋清，那么就是好的。

只要我们把一个系统中的大部分内部关系总结到一张图上，我们对这个系统就会有一个整体性的了解，即使这个时候系统出现了问题，我们也知道该去哪个模块找答案。这就是一个框架，剩下的工作都是围绕着这个框架进行的，比如你发现某些模块自己比较有经验，用到的技术自己之前都有所接触，那么你不需要花太多时间在上面，而有些模块，对于你来说比较新，你可能需要多花时间去了解其中用到的技术。你会更有侧重点，也更清楚自己的时间该花在哪。基于此，你慢慢地往这个框架中填充细节，直到最后你完全掌握了整个系统的来龙去脉。很多时候，不需要等你完全掌握整个系统，就可以接手了，在对系统的维护和开发过程中，也能让你对系统有更深的了解。

从整体到局部的过程中，你不会迷失在细节之中。从一开始你就构建了一张 “地图”，只不过一开始这张地图上只有 “国家” 没有 “城市”，在一步步地开发实践中，你往地图上填加了 “城市”、“乡镇”，以及它们之间的 “街道”，你对这张地图所代表的 “世界” 的理解会越来越深，你发现很多不足的同时，你也会慢慢地尝试延伸这张地图，让它带你见识更广阔的 “世界”。

不懂就要问

即使你有好的心态，高效的做事方法，可难免会遇到自己不理解的地方，这个时候就需要提出来。很多时候我们会觉得不好意思，觉得提问是打扰别人，其实不然，问题越早提出来，你的收益就越大，也许别人的一句回答就会帮你省去看很多无关代码的时间，也许因为你的问题，别人会把系统的相关文档填写的更加详细。

即使问出了在别人看来特别简单的问题，也并不丢人，因为每个人所擅长的都不一样，况且，你要接手的是一个别人很了解但你不了解的东西。相反，一个问题都不问才是最吃亏的，等到后面自己成为了系统负责人，出现了自己解决不了的问题，那时候是叫天天不应，叫地地不灵，这才尴尬。

不要怕问问题，别人觉得你烦那是他的问题，他的修炼不够，把该搞懂的搞懂，查漏补缺，做好自己应该做的，不放过任何一个了解系统的机会，这样，才问心无愧。

保持乐观

在我看来，接手项目是好事，是一个拓宽自己知识面，提升自己技能的大好机会。就拿我自己来说，当我清楚了上面这些方式方法后，一有机会我就会接手没人管的系统或是项目。你可能觉得好奇，你咋有那么多的时间？因为我每接手一个项目或者系统，都努力地去把它的来龙去脉捋清，尽自己所能把它优化到不会出错，并且构建相关文档和 “地图”，这样即使出问题我也可以快速定位，快速解决，所以项目经我接手后，都很稳定，不需要特别花时间维护。

有了这些积累后，我对每一个我接手的项目都保持乐观的态度，我相信我能把它变得更好，我也相信，没有白吃的饭，更没有白走的路，你走的每一步，都算数。