能用的业务系统，不欠任何人一次重写

我不会仅仅因为看不惯你的代码，就建议把应用推倒重写。

如果它能接收订单、完成收付款、支撑业务运转，就值得一次认真的评估，而不是开发者打开代码库，看几眼便宣布：换作我，会用另一种方式来写。

那当然。他有不同的工具、不同的偏好，还能看到上一位开发者付出代价后才学到的经验。但这并不自动说明，从头再来值得你花这笔钱。

重写有时确实是正确决定。不过，即使不提“现代技术栈”，这个决定也应该能在一场关于业务的讨论中站得住脚。

难看的代码里，可能藏着你仍然需要的东西

假设一家批发商有一套老旧的订货系统。界面过时，生成某份报表也很慢。新来的开发者建议把整个系统换掉。

随后，财务人员解释说，有几位客户执行协商价格；一次交货可能分两天完成；一张贷项通知单可能只涉及订单的一部分；还有一位老客户需要特殊的导出格式。

这些情况不能证明旧代码写得好。有些规则可能早就不适用了，有些可能只是应该取消的临时补丁。但在新系统开始处理真实订单之前，必须有人分清哪些该保留，哪些该舍弃。

新的结账流程再整洁，如果忘了客户约定的价格，对处理投诉的人来说就不是进步。而重新实现一个已经没人需要的变通办法，则是在花更多的钱保留一个错误。

这就是为什么旧系统值得调查。Martin Fowler 在关于渐进式现代化的文章中指出了这两类困难：现有系统的行为可能很难理清，而且其中有些行为根本不该照搬。第一步应是明确你想实现什么结果。

把问题说清楚，才有办法评估成本

“系统太老了”几乎无法帮助老板作决定。“月度报表的导出会漏掉这些记录，导致员工每次都要花一个下午处理”，才是团队可以调查的具体问题。

这两句话最终可能导向同一个决定，但不应该一开始就得到同一份方案。

对于这家批发商，我会想先跟踪一笔订单如何经过定价、库存、交货和记账，也要弄清报表究竟哪里出了问题。也许只需优化查询，也许该替换报表模块，也许现有数据结构确实无法支持所需报表，必须做更大的调整。

评估的目的，就是区分这些可能性。它应该有明确范围、有用的结论和结束条件。如果评估唯一的成果是要求再做一次更大的评估，对付钱的人就没有多少帮助。

代码质量当然重要。如果一次普通调价就必须修改应用里多个不相关的部分，或者没人能安全地部署修复，企业就在为这种设计付出成本。请把后果说明白，并拿出依据。“我不喜欢这个框架”是偏好；“这个依赖已经无法得到支持，而这些功能会受影响”才是需要解决的问题。

换掉一部分，不一定要让整个业务陪着冒险

假设问题确实出在报表模块。一种可调查的方案，是在现有系统旁边构建替代模块，用同一批示例订单比较结果，再由业务人员核对后切换过去。改进报表期间，订货流程可以继续留在原来的系统里。

这是一种值得评估的选择，不是保证所有应用都能轻松拆开。你需要知道数据来自哪里、哪个模块负责修改，以及新旧版本如何共存。

微软将这种渐进替换方式称为绞杀榕模式（Strangler Fig pattern）。其文档也说明了成本：过渡期基础设施、跨系统依赖，以及请求路由层可能成为瓶颈的风险。文档还明确列出不一定适用的情况，例如很容易整体替换的小系统，或必须尽快退役的旧系统。

认真考虑其中的思路，并不意味着你就得购买一个微服务改造项目。真正的问题是：能否在一次改变更少业务环节的情况下，交付所需的改进？

如果新旧版本要并行运行，就把这段时间纳入预算，约定如何对比、何时切换，以及如何清理过渡设施。还要问清楚：切换后如果需要退回旧系统，新产生的记录怎么办？仅仅说“我们有备份”，并不能解释昨天的订单如何在回退过程中得到保留。

有些情况下，我也会建议重写

熟悉的界面可能掩盖严重问题。失去支持的组件、反复出现的故障、无法访问的源代码，或无法满足必要业务变化的设计，都可能让继续保留应用变得昂贵或不安全。即使员工已经习惯忍受，这些问题也值得处理。

对于一个小而清晰的工具，整体替换也可能比添加临时连接更便宜。仅仅为了把迁移称为“渐进式”，就坚持维护两套系统，并没有什么价值。

我会比较每条路线还需要完成的工作：修复现有应用、替换范围明确的一部分，或者构建完整替代品。数据迁移、系统集成、员工培训、过渡期间的支持，以及退役旧系统所需的工作，都应该算进去。只给新界面报价的方案，遗漏了决策中的重要成本。

AI 可以协助阅读代码、起草修改方案、生成待验证的测试，也能加快有价值的现代化工作。但它无法自行判断，一条例外定价规则究竟是合同承诺、过时的变通办法，还是一个错误。这需要有人与业务方一起确认，再验证软件的实际行为。

签下重建方案之前

问开发者：“需要发现什么情况，你才会建议保留这个应用？”

如果不存在任何这样的情况，那你得到的就是一个预先定好的方案。在投入预算之前，先问清楚它的依据。

Rosecraft 既开发新应用，也改进现有系统及系统之间的连接。请告诉我们哪个流程让你头疼、你需要哪些变化，以及别人为什么建议推倒重来。我们可以一起确定评估范围和切实可行的下一步，无论答案是针对性修复，还是有充分理由的替换。

如果你准备好听听软件真正需要什么，即使答案会挑战那份已经向你推销过的重建方案，欢迎联系我们。你应该花钱改善业务运转，而不是让代码追赶潮流。