经常有客户关心问到源代码的问题，今天我们来分享一下。

经常有客户关心问到源代码的问题，今天我们来分享一下。

首先，什么情况下需要交付源代码？

通常定制软件开发的项目才需要交付源代码。如果你购买现成的软件产品，确实是没用源代码的，除非你买的是个开源系统的商业授权。

其次，如何判断源代码是完整的？

   

      问这个问题的通常都是非IT专业的甲方领导。其实很简单，甲方安排一位中级或以上的软件工程师来交接源代码，代码到手之后从头到尾编译、打包、部署、功能测试一遍，基本上就不可能有假。关键点是代码中间有没有夹带预先编译/封装好的代码包，如果有，是合理的第三方组件还是乙方隐藏的黑匣子。通常中级软件工程师都应该在这个问题上有足够的判断力。

　然后，能编译运行就可以验收了吗？

显然不是，还必须有跟源代码配套的软件开发文档。或者说，源代码本来就应该包含文档。需要包含的文档可能有多有少，取决于交付的是个什么软件。通常功能清单、总体设计、详细设计、编译手册、操作说明、安装维护手册都是最基础的，复杂的还可能有业务场景说明、接口文档、培训教程、测试用例、版本历史说明、已知问题说明，等等。

 没有合适文档的话，源代码就是一堆没有任何意义的“建筑垃圾”。后续要利用这些“建筑垃圾”盖房子的话，还不如重新买砖头来得快。程序员的流行话术“花时间看懂这段代码还不如重新写”反映的是好多“源代码”其实是缺失配套文档的“建筑垃圾”这样的悲惨现实。

有代码也有文档，还要看版本。信息系统项目质量管理工作中的质量审计部分，其中一个作用就是确保版本没有搞错。虽然版本搞错了也能凑合用凑合改，但价值未免打了折扣。不过能做质量审计的团队很罕见，因为这个工作很耗成本，事实上很少甲方能理解并支付，更少乙方能抵挡“省下就能少亏”的诱惑。

 最后，什么时候移交呢？

甲方肯定坚持没有代码不验收；乙方又担心给了源代码甲方就跑路了(唉，其实不给源代码甲方也会跑路)。折衷的做法是：先完成其他验收，例如功能测试，签完字，再交付源代码。这样，法律才能在乙方追讨血汗钱的时候帮上更多的忙。