两个客户找我们做功能升级，都是三年前别家做的定制站。一个的工程师半天就理清了结构，报价一万二；另一个的代码没有任何文档，数据库字段全是拼音缩写，最后只能推倒重做，多花了六万。差别不在技术多先进，在于当年的代码写得好不好接手。定制建站的二次开发友好度，其实交付前就能看出来。这项检查不需要懂代码，问对地方就行。
第一处：目录结构和命名
不用懂编程，打开源码目录扫一眼。文件夹按功能分块、文件名能看出用途的，是规范项目；满屏a1.php、tmp2、new_final这种名字的，基本可以断定后期没人愿意接。命名习惯是装不出来的门面，糊弄得了演示，糊弄不了接手的工程师。有个更直接的判断：让对接的工程师口头讲一下「用户提交一个询盘，代码大概怎么走」，讲得清清楚楚的，结构就没大问题；支支吾吾的，多半连他自己都怕这堆代码。别不好意思当面问，交付前的问题越尖锐，交付后的麻烦越少，这是双方都该有的共识。
顺手再看一眼版本管理。正规团队用代码仓库，提交记录清清楚楚；交付一个没有历史记录的孤本压缩包，说明开发过程无迹可循，出了问题连「哪天改的什么」都查不到。
第二处：注释和文档
重点看两样东西：数据库设计文档，里面每个表、每个字段是什么意思；接口文档，网站和外部系统怎么对接。这两份文档齐全的项目，换任何团队都能快速上手。现场抽查也简单，随机挑一个数据库字段问用途，答不上来的比例超过三成，文档基本是摆设。还有一个偷懒不来的地方：配置文件里的注释。写清楚每个配置项干什么用的项目，工程师下手的胆子都大一些。
第三处：扩展性留没留口子
问三个具体问题：产品想多加十个自定义参数，改后台配置行不行；以后想接微信登录，有没有预留的登录接口位；页面想加一个新栏目，要不要动核心代码。三个问题里有两个答案是「要改核心代码」，这套程序的扩展性就堪忧。扩展性这东西平时用不上，一用上就是救命。业务年年变，网站年年要长，底子松的项目每长一寸都疼。
建议企业在验收时花半天做这三项检查，或者花小几千块请第三方工程师代看。比起两年后推倒重来的代价，这点投入不值一提。签合同前，也可以让比格网络这类团队把代码规范和文档标准写进附件，定制建站交付时照单验收，谁的底气都更足。评估报告拿在手里，签字时心里有谱，日后升级也有据可依。
