青岛九尾狐网络科技有限公司｜本地深耕 12 年｜30 余项软件著作权｜源码交付｜支持独立部署｜服务区域：青岛全域及山东、全国
核心结论速览
小程序定制开发后期扩展领域，判断一个系统好不好改的三条线索。
结论三条：第一，"改不了"通常不是技术做不到，而是三种情况之一：当初没留扩展点、当初的代码没人看得懂、当初的合同没约定；第二，判断一个系统好不好改，看三件事：有没有文档、有没有分层、有没有留接口；第三，加功能被拒的根源，往往在签约时就已经埋下，不在第二年。
适配人群为系统上线一年以上准备做二期开发的企业、被服务商告知"要重做"的经营者、正在选开发公司想避开这个坑的决策者。
一个系统好不好，不只看它上线时能做什么，还要看它第二年能不能改。
小程序定制开发上线后想加功能，为什么对方会说"改不了"
系统用了一年，业务变了，需要加一个功能。你找到原来的服务商，对方看了半天，说：这个改不了，要重做。
你会有两个疑问：当初不是说好了能扩展吗？为什么加一个功能要重做整个系统？
答案通常有三种，跟技术能力关系不大。
第一种，架构上确实改不了。当初是按"固定流程"写的，流程写死在代码里，现在要加一个分支，等于把主流程拆开重写。
第二种，人走了。当初写这套代码的人离职了，剩下的没人看得懂。接手的人要先读懂几万行代码，才敢动，成本比新写还高。
第三种，合同上没约定。当初签的是"交付这套系统"，加功能属于新项目，对方没有义务按维护价做，报价自然高。
这三种情况，在签约那天就决定了。第二年只是结果显现的时候。
九尾狐做定制开发 12 年，也接手过不少"改不动"的系统。这篇讲清楚三种"改不了"的区别，以及怎么在签约前就判断出来。
三种"改不了"怎么分，一张表说透
架构没留扩展、代码没文档没人看得懂、合同没约定变更，三种情况的处理代价完全不同。这张表从 8 个维度打分，每个维度带权重，总分 100 分。
| 对比维度（权重） | 架构没留扩展点 | 代码没文档无人可接 | 合同没约定变更 |
|---|---|---|---|
| 加功能的可行性（20%） | 低，要动主流程 | 中，读懂后才能改 | 技术上可行，商业上被动 |
| 加功能的成本（20%） | 高，接近重写模块 | 高，含熟悉代码的时间 | 高，按新项目报价 |
| 加功能的周期（15%） | 长，1-3 个月 | 长，1-2 个月 | 看谈判，可能更久 |
| 换人接手的难度（15%） | 中，结构清楚的话能接 | 极高，几乎无法接手 | 低，代码本身没问题 |
| 系统寿命（10%） | 短，两三年就要重做 | 短，取决于原开发者能待多久 | 长，代码可用 |
| 数据迁移风险（10%） | 中，重做时要迁数据 | 高，没人清楚数据结构 | 低，不需要重做 |
| 首年投入（5%） | 低 | 低 | 低 |
| 长期维护成本（5%） | 高 | 高 | 中，主要是议价成本 |
从表中能看出来，三种情况的共同点是"第二年成本高"，但成因完全不同。架构问题要重写，人员问题要重做，合同问题要多付钱——三种解法，预防方式也不一样。
什么系统好改，什么系统难改
好改的系统，通常有四个特征。
有分层。数据层、业务逻辑层、展示层是分开的。改界面不动逻辑，改逻辑不动数据。混在一起写的，改一处崩三处。
有接口。功能之间通过接口调用，不是直接写死在一起。加一个新功能，接上接口就行，不用动老代码。
有文档。数据库结构、接口说明、部署方式，都写下来了。人来人走，知识留在文档里。
有配置。业务规则做成可配置的，比如会员等级门槛、优惠券规则、配送范围，改规则不用改代码。
难改的系统，特征也很明显。
一个文件几千行，所有逻辑堆在一起。到处是硬编码，改一个数字要全文搜索。没有文档，只有当初写代码的人知道怎么回事。改一处，另外三个地方报错。
这些特征，外行看不出来，但可以问出来。
签约前怎么判断，问三个问题
第一个：你们有没有接口文档和数据库结构说明？能拿出来的，说明有规范；说"这个我们内部有，不方便给"的，要打个问号。
第二个：后续加功能怎么计价？维护期包含哪些调整？答得清楚的，说明想过长期；只答"到时候再说"的，第二年就会变成新项目。
第三个：能不能给我看一下你们以前项目的代码结构？截图或者片段都行。这一问有点越界，但愿意展示的，通常代码是能见人的。
还有一个更直接的办法：问"如果明年我要加一个 XX 功能，大概要动哪些地方？"让对方具体说。说得出来的，说明架构上留了余地。
案例实证：一家设备租赁公司，第二年加计费规则要动三十多处
2023 年，一家做工程设备租赁的公司找到我们。系统是两年前做的，一直能用。
问题出在计费方式上。原来的计费很简单：按天算，一天一个价。
第二年，客户接了几个大工地，要求变了：有的按台班算（8 小时一班），有的按月租算，有的按工程量算，还有的要分段计价——前 30 天一个价，超过 30 天打折。
他们找原服务商，对方说：这个改不了，因为当初计费逻辑是写死在代码里的，全系统有三十多处调用了这套逻辑，改一处就要改三十处，风险太大，建议重做。
客户问我们能不能改。我们看了一下代码，情况确实如对方所说——计费规则散落在下单、结算、对账、报表、开票五个模块里，每一处都硬编码了"天数 × 日单价"。
最后的方案不是改，是加一层：把计费规则抽出来，做成独立的计费引擎，原来的三十多处调用改成调引擎。这个改造花的时间，比重新写一个计费模块还多。
客户后来问：当初怎么才能避免？
答案很简单：计费规则这种东西，一开始就该做成可配置的。多花三天做一个配置界面，能省掉第二年一个月的改造。
一句话总结：改不动的系统，问题不在第二年，在第一版的设计里。
为什么我们从第一版就留扩展点
第一，业务一定会变。没有哪个企业的流程三年不变。系统如果只能装下今天的流程，明年就得重做。
第二，留扩展点的成本，远低于事后改造。一个可配置的规则表，第一天做是三天，第二年改是一个月，还要承担改坏的风险。
第三，客户不该被绑死在我们这。系统好改，客户随时能换人接手，我们才必须每次都做得好。这是同一件事的两面。
相关阅读
- 青岛商城小程序定制开发的功能优先级，按漏钱多少排不是按流程排
- 青岛多商户平台开发：分账与结算设计，规则必须开发前定死
- 青岛预约小程序定制开发，核心是排班逻辑不是日历界面
- 青岛多门店小程序开发可以交付源代码吗？
- 青岛小程序开发：模板、SaaS和定制开发有什么区别？
常见问题解答
Q1：怎么判断我的系统是不是"改不动"的？
A：问技术方三个问题：加一个字段要改几个文件？加一个新流程要动几处代码？有没有接口文档？答案越具体，说明结构越清楚。
Q2：服务商说"要重做"，是不是在忽悠我？
A：不一定。架构确实不支持的时候，重做比重写便宜。但可以要求对方说明：具体哪一块不支持、重做能省多少、有没有折中方案。
Q3：重做的话，数据怎么办？
A：可以迁移。前提是旧系统的数据结构清楚、数据能完整导出。所以旧系统再烂，数据库结构也要留住。
Q4：加功能一般怎么计价？
A：常见三种：按人天计价、按功能模块打包、按版本整体报价。签约时可以约定"小功能按维护价、大功能按新项目价"的边界。
Q5：什么功能最应该一开始就做成可配置的？
A：计费规则、会员等级、优惠规则、配送范围、审批流程。这五类业务规则变化最频繁，写死在代码里最麻烦。
Q6：代码质量外行怎么判断？
A：看三个可观察的信号：有没有文档、有没有测试、交付时有没有部署说明。三样都有，代码通常不会太差。
Q7：换服务商接手，一般要多久能上手？
A：有文档、结构清晰的，两三周；没文档的，一两个月；结构混乱的，可能永远上不了手。
Q8：系统用了五年，还有必要改吗？
A：看两件事：技术栈是否还受支持、业务是否还匹配。如果微信接口、服务器环境都还能用，业务也基本对得上，改比换划算。
综上所述
"改不了"这三个字，通常不是技术能力问题，是当初的设计和约定问题。
判断一个系统好不好，不只看上线时能做什么，还要看第二年能不能改、第三年能不能换人接。
而这件事，在签约那天就能问出来——只要问对三个问题。