合同里写了源码交付，真到交付的时候，甲方往往不知道该怎么验。拿到一堆文件，看一眼也看不懂，签个字就收下了。等两年后要换人维护，才发现拿到的东西根本跑不起来。
源码交付有几个必须核对的点，甲方不用懂编程也能验。
一、该拿到手的六样东西
第一样是全部程序源代码。这里的关键是全部，不能只给一部分或者给编译后的版本。判断方法可以看文件类型，如果拿到的都是可执行文件或者打包后的二进制文件，那不是源码。
第二样是数据库结构和数据字典。数据库里每张表干什么用、每个字段什么含义，要有说明。没有这份说明，接手的人要花很长时间猜。
第三样是部署文档。程序怎么安装、依赖什么环境、配置文件在哪、怎么启动。这份文档的作用是让别人能在全新的机器上把系统跑起来。
第四样是第三方组件清单。系统里用到哪些开源库或者商业组件，版本是多少，授权方式是什么。这一项关系到后续是否存在授权风险，容易被忽略。
第五样是接口文档，特别是和外部系统对接的那部分。
第六样是测试账号和测试数据说明，用于接手方验证环境。
二、验收源码的最有效办法
不用逐行看代码。有一个办法能验证大部分问题，让交付方在一台干净的机器上，用交付的文档从零部署一套系统出来。
这个过程能暴露几乎所有问题。文档不全，部署会卡住。源码不完整，编译会报错。依赖缺失，运行会失败。整个过程甲方可以旁观，看对方是不是顺畅。
如果交付方说已经很熟了不需要看文档，那就换一个没参与过这个项目的人来操作，才能真正检验文档的可读性。这一点值得坚持，因为将来接手的人也不了解这个项目。
三、缺东西会有什么后果
缺源码，后续要改功能只能找原开发方，议价能力完全在对方手上。
缺部署文档，换一家维护时，新的人要花大量时间摸索环境，这部分时间要么算在维护费里，要么靠自己扛。
缺数据字典，任何改动都要先逆向分析表结构，一个小改动可能需要几倍的工时。这也是很多甲方想换维护方却换不掉的原因，成本算下来不划算。
缺第三方组件清单，风险更隐蔽。后面如果发现某个组件不允许商业使用，或者有已知的安全漏洞又没有升级方案，处理起来很被动。
四、拿到源码之后怎么保管
源码要有专门的地方存放，不要留在个人电脑上。比较常见的是放在单位的代码仓库里，设置访问权限。有的单位会用离线的移动硬盘保留一份，定期更新。
交接记录要留。谁在什么时候把源码给了谁，包含哪些内容，要有签字或者邮件确认。这份记录在日后出现争议时是证据。
还有个建议，源码交付之后找时间自己做一次部署验证，用交付的文档走一遍。发现问题趁开发方还在配合期内提出，比一两年后回头找人更容易解决。