卡夫卡说：一切障碍都可以粉碎我。这话如果从铁中棠口中说出来，就是：任何代码都可以玩儿死我。

你估计不愿意像铁中棠那样被别人的代码玩儿死。So，假如你真的要接手别人的代码，怎样才能不被玩儿死呢/p>

虽然你可能会说，听了很多道理，依然交接不好代码，可作为经常被别人的代码玩儿的欲仙欲死的老司机，我有些话如鲠在喉，不吐不快。

当你被要求接管要离职的程序员的代码时，如果能注意以下几点，就有可能活着从他的代码里爬出来，而那些不能将你击溃的代码，都将成为你成长的垫脚石。

• 1. 产品需求与业务流程文档

产品需求与业务流程文档，这些是你先要找到的，你接手的代码，必然和某个产品需求相对应，必然实现了某个业务流程，先了解产品需求和业务流程，才能更好的读代码。

假如你的团队就是没文档，Ok，也可以要求离职或转移战线的这位程序员把需求描述出来，把业务流程画出来。

• 2. 测试环境

了解了产品需求和业务流程，最好能体验一下软件，从用户的角度来理解软件的使用。这个时候你要么需要生产环境，要么需要测试环境。哪个环境不重要，重要的是，你需要一个能Run，能体验的软件。

• 3. 业务流程在代码层面的体现

负责交接代码给你的那位同事，要么在办离职，要么已经介入了其他产品，眼下很可能已无心恋战，但你心里要清楚，只有他才能提供代码层面的东西，比如

• 类图
• 模块划分说明
• 数据流图
• 时序图
• 状态图

所以，你需要他整理一些文档和图表出来。你可以告诉领导你需要上面的东西，让领导和他沟通，让他在离开之前准备好这些文档给你，并留一些时间以便你熟悉。

• 4. 读代码，不死不休

有了产品需求，有了业务流程，有了代码设计相关的文档和图表，接下来你就该死磕代码了：

• 5. 开发环境与调试

有的产品需要比较复杂的开发环境配置，一定要提前做好，让即将离开的同事辅导你搭建好开发环境，这样你就可以利用“调试”这个强大的武器来快速理解代码了。

• 6. 调试

调试是接手别人代码时的利器，如果你看不明白一个业务在代码层面是怎么体现的，也看不懂代码之间的调用关系，那最好的办法就是调试。从一个业务的起点所对应的代码开始调试，一步一步跟进去，就能快速理清函数调用链。

• 7. 树立可实现可衡量的目标

程序员的工作交接，尤其是代码交接，怎样才算顺利完成呢/p>

这简直就是一个谜！

没人说得清楚。

所以，你最好给自己梳理一些可衡量的、可实现的目标。比如读懂A、B、C三个业务流程……

最好，找一个Bug或者一个新增的功能，带着目的去读代码、修改代码，有目的，有目标，有时间盒，就容易投入，容易读进去，容易掌握与Bug或新增功能相关的代码的逻辑与流程。

• 8. 输出、分享与重构

你在读代码时，如果能撇开给你交接工作的程序员提供的文档，按自己的理解，自己绘制类图、数据流图、时序图、关键业务流程对应的函数调用关系链等，就能更快的掌握别人的代码。

如果你还能将你理解到的东西，讲给其他人听，并且讲明白，那Ok，你真的理解了别人交接给你的代码。

再进一步，如果你在理解现有代码的基础上，可以识别出哪些部分实现得逻辑不清晰或有待改善，然后可以结合业务与自己的理解将其重构，那就真的是完全接手了别人的代码，别人的代码与你的代码就没有差别了，它们终将成为你的代码。

最重要的事儿

如果你总是看见代码多就发愁，看见代码脏乱差就诅咒埋怨，看见代码逻辑复杂就头疼，搞不清调用关系就放弃，那你可能永远也变不成代码的主人，只能一次又一次被代码蹂躏。

所以，其实交接代码最重要的事儿，就是：

不要被浩渺如烟并且陌生怪诞的代码吓得不敢动弹，现在就开始读，立刻，马上，坚持十分钟，再坚持十分钟，你就能妙悟真谛。

相关阅读：

• 这样读源码，不牛X也难
• 做事的常识

关注“程序视界”，一起成为更好的自己：