网站开发二次开发难，多半是当初架构没留口子

      见过一个例子。客户想在站上加个会员积分，工程师翻了两天代码，最后回了句：重做比改快。客户当场就懵了，明明花钱请人做的东西，怎么想添个小功能都不行。这种事在行业里不新鲜，问题多半轮不到后来的团队背，根子埋在最初那版网站开发里。

最常见的情况，代码是一锅粥。页面、逻辑、数据全塞在一个文件里，改一处牵一串。想加个字段，得先弄清这个字段在哪些地方被引用过，翻十几处才发现还有地方写死了。这种站别说加功能，就是换个颜色都让人心里发虚。更麻烦的是没人敢动它，动一下不知道哪儿会冒错，工程师宁可绕开原来的写法，另起一套，日子久了，同一个站里躺着三四种风格并存的老代码。

再就是数据库没留余地。当初建表的时候，需求是“产品就三个分类”，表结构照着三个分类硬编码。一年后要加第四个分类，得改表、改代码、改后台，牵扯一圈。稍微讲究点的做法，是把这类可变的量做成配置项，加分类只是后台点几下的事，写死就只能动刀。字段命名也是同理，有的站里同一个含义有叫 type 的，也有叫 kind 的，接手的人得对着代码猜半天。这种乱谈不上技术难，多半是当初没人立规矩。

还有一种是自己把自己锁死。用了某个小众框架，作者早不维护了；或者为了省事接了某个插件，那个插件停止服务，整站跟着趴窝。当时看着快，后面全是债。判断这笔债大不大，有个简单的办法：问清楚这套东西升级一次要动多少地方，对方要是答“最好别升”，这笔债小不了。

      文档也算一项。有的团队交付就扔一堆代码过来，没有部署说明，没有字段注释，连后台管理员是谁建的都查不到。后来接手的人光是读懂它就要花掉大半预算，真正改功能的钱反而没剩多少。最要命的是当初写代码的人早就离职了，想问一句都找不到人，只能自己从头捋。

那怎么避？谈网站开发的时候别只听“我们用最流行的技术”。可以具体问几句：代码分不分层，数据库里哪些字段是配置项，接口有没有留扩展位，交付时给不给文档。问得出来，说明人家平时就是这么做的；问不出来，那多半是把活干完就走的思路。还可以让他举个例子，说说以前哪个客户提过需求变更，当时是怎么处理的，答得顺畅的，一般心里有底。

还有个务实的建议，预算允许的话，让开发方在合同里留一小笔后续迭代的额度，把扩展当成流程的一部分，每次改动就不用重新立项。顺带说一句，为什么后来接手的团队报价总比原来那家高？因为人家得先花时间摸清家底，这部分工夫没人愿意白干，自然摊进报价里。客户看着心疼，其实这笔钱付的是上一轮省掉的功课。

改得动，站才活得久。