很多团队一遇到老系统问题，第一反应就是问一句：
这个系统到底该重构，还是直接重做？
但我自己的经验是，这个问题如果问得太早，最后大概率会把项目带偏。 因为真正该先判断的，不是“技术上能不能重构”，而是这个系统现在的问题，到底是局部老化，还是整体失控。
有些系统虽然代码老、写法旧，但业务还算稳定，边界也清楚，这种情况往往更适合渐进式重构。 但也有一些系统，表面上看像是技术债，实际上已经是流程、权限、数据结构、历史兼容逻辑全缠在一起了。 这种时候如果还坚持“边跑边修”，最后常见的结果不是省成本，而是持续往里填坑。
所以比起先站队“重构派”还是“重做派”，我更建议先看下面这 4 个维度。
1. 先看系统的问题是在“代码层”，还是已经蔓延到“业务层”
如果一个系统主要问题是代码难维护、模块耦合、性能一般、开发效率低，但业务流程本身没太大问题，那通常还属于可以重构的范围。
但如果你发现这些问题已经同时出现：
- 业务流程本身就混乱
- 不同部门对系统理解不一致
- 权限设计长期靠补丁维持
- 数据口径经常对不上
- 旧功能没人敢删，新功能又只能继续叠
那这就不只是技术改造问题了。 这类系统更像是“历史问题被代码固化”了，继续重构不一定能把问题拆开，反而可能把旧包袱一起保留下来。
简单说：代码老，不一定要重做；但业务和系统结构一起乱，通常就要重新规划。
2. 看旧系统里还有多少“值得保留的稳定资产”
很多人一提重做，就容易走向另一个极端：觉得旧系统一无是处，推倒重来最干净。
但实际项目里，旧系统往往还是有一些东西值得保留，比如：
- 被业务长期验证过的核心流程
- 稳定的基础数据结构
- 已经跑顺的关键报表口径
- 和其他系统打通好的接口关系
- 用户已经习惯的操作路径
如果这些“骨架”其实还在，只是外围实现脏了、慢了、难维护了，那更适合做的是保留稳定资产，逐步重构外围模块。
真正适合重做的情况，往往是连这些基础资产本身都已经有问题。 比如核心模型一开始就设计错了，或者流程已经和当前业务完全脱节。 这种时候继续在旧壳上修，边际收益会越来越低。
所以判断时一定别只盯着“旧”，而要问一句：
这个系统里，到底还有没有值得继承的东西？
3. 看你现在要解决的是“维护成本”，还是“业务升级”
这是很多团队最容易混淆的一点。
如果你当前最痛的是：
- 改一个功能牵一大片
- 新人接手困难
- 开发成本越来越高
- 线上问题反复出现
那你面对的核心问题更偏维护成本。 这种情况下，很多时候重构就够了，因为目标是把系统变得更稳、更容易继续维护。
但如果你现在真正要做的是：
- 增加新的业务模式
- 大幅调整角色和权限体系
- 支持新的组织结构
- 接新渠道、新终端、新系统协同
- 把原来分散的流程重新整合
那这已经不是“修旧系统”了，而是借这次机会做一次业务升级。 如果目标是升级，旧系统就未必还是一个好的承载基础。
换句话说：
- 重构更适合“让原来的系统继续活得更好”
- 重做更适合“让系统进入下一阶段”
两者不是谁更高级，而是目标不同。
4. 最后再看资源：时间、预算、团队承受能力够不够
很多判断在前面三步其实已经很清楚了，但最后仍然会被资源限制拉回来。
因为“适合重做”不代表“现在就做得起”。
重做通常意味着：
- 前期梳理成本更高
- 旧系统和新系统可能要并行一段时间
- 验收、迁移、培训、切换的风险更大
- 团队短期压力会上升
而重构虽然没那么理想，但它有时候更现实： 可以边跑边改，分模块推进，组织阻力也更小。
所以项目里最怕的一种情况，不是选错，而是：
明明资源只够做局部修整，却硬上全面重做；或者明明系统已经烂到该重来了，还因为怕麻烦继续缝缝补补。
真正稳的做法，是把“理想方案”和“当前能落地的方案”分开看。 有时候最合理的答案不是纯重构，也不是一步到位重做，而是：
先用一期把最危险的部分拆出来，逐步过渡。
一个更实际的判断顺序
如果你现在也在纠结旧系统该怎么处理，我会更建议按这个顺序判断：
- 先确认问题是技术债，还是业务和系统一起乱了
- 再确认旧系统里还有多少东西值得保留
- 再看这次目标是降维护成本，还是做业务升级
- 最后再结合时间、预算和团队状态决定推进方式
这样判断下来，结论通常会更稳。 因为很多项目并不是“技术上怎么选”难，而是前面的问题没拆开，就急着做决策。
结语
旧系统该重构还是重做，从来不是一句话能拍板的事。 真正有价值的，不是先选立场，而是先把系统的问题类型、业务目标和资源约束看清楚。
不然很容易出现两种常见结果：
- 该重做的项目，被拖成了长期修补
- 该渐进重构的项目，被做成了高风险重建
如果你也在评估这类项目，可以再看我这篇展开版： sphrag.com/zh/blog/int…
