作为一名程序员，我跳交接槽过不少公司，也接手过其他人交接的工作。所以我想，如何做工作交接是比较合理正确的呢？

通常我们维护的项目用到的功能模块很多，各个模块的底层技术细节也非常复杂。

虽然说代码应尽量遵循最佳实践，但功能迭代多了，里面难免会有一些针对业务的特殊代码，或者技术差的同事写了可读性差的代内容有码。

所以别想只是通过阅读代码就能对业务有深刻的认识。一个人通常不能掌握所有模块的细节，最多只是清楚脉络。

对应的是每个人都有各自负责的主要模块。产品经理有开发需求找熟悉对应模块的开发，这样开发效率高。

但问题什么是如果他要离职，交接工作交接得不好就可能会出现线上事故，是不稳定的点。

对于大厂，管理者会注意让一个模块让多个人熟悉，多花点时间也要避免这个风险。对于小厂，则是怎么快怎么来。

文档很重要

一说到交接，就不得不说交接文档。

离职的人应该提供尽量详尽的文档，并需要经过同样熟悉相关模块的同事的过目。

但是文档不是万能的，甚至会产生误导。离职的同事可能会写错或写漏重要的信息，可能给你的是一份老旧的文档，后来迭代的变化内容并没有更新到这篇文档。

所以最好让离职的同事陪你过一遍模块的功工作能。

“如果遇到什么问题，随时找我”

这是离职的同事总是会说的一句话。

但这是一句无法让人安心的话。因为如果交接的时候没有处理好，接手的同事要么根本不会找你，要么是出了事故才会找你。

原因是接手的同事并不知道哪里有问题，他发现不了盲区，直到陷入进去，然后发现为时已晚。

对于一些流程或配置工作，可以让离职的同事演示开发的整个流程，让接手的人看着，问他有什么不懂的地方。然后再让接手的同事自己操作一边，找出他的盲区进行纠正。

当然，最好的方式是进行实战，实战中往往能发现练习中的一些疏漏的地方。

对于代码模块来说，则应该具体写一下各个类、函数的功能，说明一些 trick 写法。

对工作开发来说，接手别人的代码是非常痛苦的事情，尤其是那些因为不满公司赶着跑路的同事。他们可能还会在代码里下毒，让你欲仙欲死。

考虑到离职的突发性、交接时间短、离职者不负责任什么等特点，最好的方式还是平时让多个人负责同一个模块，这样交接时公司才不那么被动。