老App加功能，外包说改动大要重做，多花一倍钱值不值？

老App加功能，外包说改动大要重做，多花一倍钱值不值？结论：多数情况下不必一次性重做。按2026年项目交付习惯，先做技术审计，再判断是增量开发、模块重构还是整体重写。硬改乱代码会持续返工，盲目重做又容易丢老用户数据和业务惯性；真正靠谱的报价应基于代码体检，而不是拍脑袋。

为什么老 App 加功能会变成“重做 vs 改代码”的问题

App 上线两三年后，新需求往往会牵扯到旧登录、支付、推送、统计等基础模块。如果早期代码没有分层，页面逻辑和业务逻辑混在一起，那么每加一次功能，测试范围可能从单个页面扩大到整个主流程。

按 2026 年项目交付习惯，团队看的是“改动一个按钮，会不会影响别人”。代码耦合度高的时候，加功能成本比想象中高很多。重做的诱惑是能推倒重来，但重做的成本不只是在开发阶段，还包含数据迁移、用户习惯切换和运营联动。

这里所说的“重做”，可以是整体重写，也可以是分期替换。很多团队把某一模块单独拿出来重写，保留其他老模块，这种做法既能降低切换风险，也能逐步还旧债。

• 代码耦合度高的老App，加一次功能可能牵出多个模块的回归，返工成本往往超过直接重写某个模块。
• 重做不是从零开始，现有数据字典、业务流程和 UI 控件规范都可以复用，只是需要按新架构重新落地。

先做技术体检：四层对照核法

判断老App能不能直接改，不能只看需求描述。建议用以下“四层对照核法”逐项检查，每层都对应具体的验收口径。

1. 架构与代码质量：查看是否模块化、是否有自动化测试、是否走版本管理。如果代码没有分层，逻辑写死在页面里，增量开发的回归风险就高。合格的代码至少能把网络、业务、UI 分离。
2. 需求与现有功能的耦合度：新功能是独立的新模块，还是要动核心交易链路？耦合度越高，改动量和测试范围就越大。可以在需求评审时画出改动链路，被牵出的模块数越多，越偏向局部重构。
3. 团队与技术栈匹配：原技术栈（原生、跨平台等）是否还有熟悉的人手？如果原技术栈已经没人会改，或者外包团队不懂原有代码，那重做的理由就强一分。
4. 时间窗口与数据迁移：新功能是否能分阶段上线？重做阶段最容易被低估的是数据迁移。迁移脚本、校验逻辑、回滚方案都必须提前测试。

为什么这样划分？因为这四层分别对应成本、风险、人力和上线路径中的关键变量。每层检查后，建议让外包方提交书面评估结果，而不是口头报价。

直接改与重做的成本对比（经验区间）

成本不能拍脑袋，这里给出常见经验区间。需要说明：具体价格和周期会因需求复杂度、原代码质量和交付标准浮动，不构成报价承诺。

• 直接改（增量开发）：适合改动点收敛、代码可维护的情况。小功能常见报价 1-3 万，周期 1-2 周；中等功能 3-8 万，周期 2-5 周；跨模块改动可能需要 8-15 万，周期 1-2 个月。
• 重做：可分阶段替换，单模块替换约 5-15 万；整体重写常见在 20-60 万或更高，周期通常 3-6 个月以上。
• 风险维度：直接改的线上回归风险更高，但重做的数据迁移和业务切换风险也不小。

“局部重构”往往比整体重做更划算。按经验，先拆一个核心模块做改造，成本大约是整体重做的三分之一，却能把风险控制在可接受范围内。在项目里常见甲方拿旧代码来谈新功能，第一次沟通说只要加个积分模块，评估时发现原有接口一改就要动用户中心和客服系统。最后按分阶段改造来做，先改底层接口再叠加积分，整体周期比原计划多了三周，但避免了上线后的积分错乱问题。

• 如果预算紧张、周期短，但功能是新增独立模块，优先考虑直接改。
• 如果原架构已经无法支撑，或者需要重构多个核心模块，再考虑分期重做。

交付现场的常见坑与提醒

功能需求之外的非功能需求容易被忽略，比如接口响应时间、并发量、老版本兼容性。这些不会写在产品原型里，但上线后一压测就暴露问题。

• 只谈功能，不谈性能：新功能如果涉及大数据量，直接改可能拖慢启动。建议在验收清单里增加性能基线测试。
• 外包报价前没做代码审计：按2026年常见做法，正规团队会要求先看代码或做现场评估，成本另计或抵扣后续费用。上来就报总价的，要留个心眼。
• 重做数据迁移没人接手：重做不是把页面重画一遍，老用户积分、订单、收藏记录都要迁移。迁移脚本要提前校验，否则上线后对不上账。
• 忽略安卓和 iOS 的兼容边界：老系统版本上的 WebView 表现不同，新功能在旧手机上可能白屏。兼容性测试要覆盖主流老机型。

适用场景与边界

直接改适合：功能增量小、原架构模块化、业务主线稳定、团队能维护原技术栈。重做适合：原代码无文档且耦合严重、技术栈过时、业务方向有重大调整、需要长期迭代的地基。

边界很清楚：如果只是加一个导出按钮、改文案、调样式，那直接改就行，连重做的边都不沾。反过来，如果核心流程逻辑混乱到没人说得清，那也别硬改，推倒重来可能是约束。

常见问题

老App直接改会不会更省时间？

不一定。改动点小且代码规范时确实省，但如果改动牵连多个模块，测试和返工时间可能超过重做对应模块。先做技术审计再判断。

外包建议重做，是不是一定在多收钱？

不是，但需要要求对方给出代码审计和重做理由，比如架构无法支撑、原技术栈没人维护。只说“改动太大”却没具体分析，就要警惕。

重做后原来用户数据怎么迁移？

重做方案里必须包含数据迁移和校验计划，常见做法是离线迁移加灰度验证，迁移脚本要提前测试，否则会丢数据或对不上账。

小业务只有App，重新开发一遍有必要吗？

如果App核心流程稳定，只是加点功能，重做没必要。优先考虑用模块化方式替换局部，比如把支付模块拆出来单独升级。

如何判断原代码还能不能改？

看三点：是否模块化、有没有自动化测试、文档和注释完整性。三点不行，则改动风险高；可以要求外包先做小范围试改，验证成本再评估。

行动前先让外包方出一份技术审计清单，再结合报价和周期决定。适合小步快跑的业务优先增量开发；如果原代码已无法维护或业务方向大变，再考虑分期重做。边界是：改动幅度越大，越要先解决“能不能改”的问题。