Web Engineering · 最小必要干预
网站系统总是需要修复：什么时候该修复、稳定化、现代化，还是重建？
缺陷的数量、项目的年龄或技术栈的复杂程度，本身并不能回答系统需要改动多少这个问题。
在投入大额预算或做出架构决策之前，重要的是先确定真正的原因、其影响的深度，以及能够消除限制、同时又不会不必要地扩大工作量和风险的最小必要干预级别。
当一个网站系统经常出现新问题时，企业通常会倾向于两种截然相反的做法。
第一种是继续逐个修复每一个新出现的缺陷。
第二种是认定系统已经复杂到不如彻底重做或更换。
这两种做法都可能是错的。
如果可见的故障只是更深层限制的表现，局部修复并不能解决问题。但错误积累得多，也不能就此证明大规模现代化是合理的。
真正的问题是：
究竟是什么在限制这个系统，这种限制的影响范围有多大，怎样的最小必要改动才能消除它？
企业在投入大量技术工作量、预算或确定实施方向之前，正是应该先回答这个问题。
为什么判断错改动规模会有风险
干预太小，可能只是消除了症状，却让根本原因保留下来。
于是类似的问题会再次出现，小的改动需要越来越多的临时应对办法，改动结果也变得越来越难以预料。
但也存在相反的风险。
如果把一个有限的问题立刻变成一个大规模系统重建项目，随之而来的不只是原来的任务，还会出现新的复杂问题：数据迁移、新旧部分的兼容性、集成方式的变更、向新方案的过渡，以及上线本身的风险。
因此正确的做法既不是「尽量少做」，也不是「尽量多重建」。
需要的是最小必要的干预程度：既能消除真正的限制，又不会不必要地扩大工作量和风险。
症状并不能反映问题的真实规模
用户察觉到故障的位置，不一定就是问题根源所在的位置。
结账时出现的错误，未必与商店界面本身有关，而可能与数据、外部集成、状态处理、环境配置或交易逻辑有关。
界面不方便使用，有时确实是 UX/UI 问题。但有时它只是反映了更深层的限制：系统收到了相互矛盾的数据，或者无法明确判断某个流程所处的状态。
发布之后反复出现的故障，也不能自动说明应用需要现代化改造。原因可能在于不同环境之间的差异、人工操作、检查不足，或缺少可靠的回滚机制。
因此，问题反复出现是一个重要信号，但还不是诊断结论。
错误的数量同样不能决定问题的深度。
五个缺陷可能只是五个彼此独立的局部任务。反过来，一个很小的功能也可能暴露出系统性限制——如果要交付它，必须同时改动前端、API、数据、集成和发布流程。
更重要的是理解：
改动的影响范围有多大，为了得到可预测的结果，需要触及系统中多少相互关联的部分？
四种不同的干预级别
这些并不是必须依次经历的阶段，而是四种彼此独立的决策类别。
局部修复
适用于原因确实有限、系统相邻部分保持稳定、修复不需要引发一连串相关改动的情况。
在这种情况下，扩大工作范围没有意义。
稳定化
适用于整体架构依然可用，但改动和运维已经变得过于不可预测的情况。
原因可能在于发布流程不稳定、环境之间存在差异、集成脆弱、错误处理薄弱，或缺少可靠的回滚机制。
稳定化本身可以是一个完整的最终结果，不一定要走向现代化。
分阶段现代化
当系统现有的结构已经明显让日常改动变得困难时，就需要现代化。
简单的任务牵涉到的相关部分越来越多，职责边界变得模糊，陈旧的 API、数据模型或集成也在持续限制系统的进一步发展。
如果系统可以安全地分部分改动，就没有必要把这变成一次性的整体改造。
有限重建
有时，针对某个具体部分的渐进式路径不再合理。
这时，对该部分进行有限替换可能是合理的选择。
关键词是有限。
在开始之前，必须清楚具体替换什么、保留什么、需要支持哪些数据和契约、过渡将如何进行，以及如何验证结果。
这并不是「从零重写一切」的决定。
第一次技术评审必须确定什么
在选择服务或确定实施规模之前，需要先明确问题本身。
一次好的评审应当为企业提供四个答案：
- 真正的原因在哪里，哪里只是症状；
- 问题的影响范围有多大；
- 哪一级别的干预是足够的；
- 哪一条后续技术路径真正对应这个原因。
在选择干预级别时，还需要考虑改动之间的依赖关系、过渡风险、能否安全回滚，以及如何验证结果。
结果可以呈现为一张决策地图：
局部修复 / 稳定化 / 分阶段现代化 / 有限重建。
只有在这之后，选择具体的实施方向才有意义。
应用架构问题可能导向 Advanced Web Development。
环境、发布或回滚问题——导向 DevOps。
目录、订单、支付或 ERP/CRM 集成方面的限制——导向 E-commerce。
已确认的界面或用户流程问题——导向 UX/UI。
但这并不是一张自动对应表。
结账时出现错误，本身并不意味着就需要一个 E-commerce 项目。界面不方便使用，也不能证明需要重新设计界面。发布后反复出现的故障，同样不能证明需要重建应用。
先确定原因。
然后确定足够的干预级别。
最后才是实施方式。
评审的任务不是证明需要一个大项目，而是在问题属于系统性时不要做得太少，在较小的干预就足够时不要做得太多。
从哪里开始
如果一个网站系统经常需要修复，第一次沟通并不需要预先在「修复」和「重写」之间做出选择。
更有帮助的做法是带来一个反复出现的问题，以及它出现的时间和在哪些改动之后出现的几个具体例子。
第一次技术评审应当确定：
原因 → 影响范围 → 足够的干预级别 → 后续技术路径。
在此之后，才可以与 Dazoro 讨论具体的工作量——或者确认并不需要一个大项目。
核心问题始终不是：
「修复，还是重写？」
而是：
怎样的最小必要改动程度，才能在不带来不必要风险的情况下消除真正的限制？