大型重构策略
重构不是推倒重来，而是重建可变更性
很多团队一提“重构”，脑子里浮现的画面还是：
- 把旧代码扔掉
- 用新框架重写
- 一次性切到新方案
这类想法很容易让人兴奋。
也很容易把项目带进风险高峰。
更成熟的理解应该是：
大型重构的目标，不是让代码看起来更现代，而是重新获得系统的可变更性。
也就是说，真正的问题不是：
“现在这套代码丑不丑？”
而是：
“这套系统是不是已经难到让团队持续交付变得昂贵、缓慢且危险？”
为什么“可变更性”是最关键的判断词
重构往往不是为了某一个短期功能。
它是在为未来一段时间的持续变化买路。
一个系统可能现在还能跑。
但如果它已经出现这些迹象：
- 改一点就连锁影响很多地方
- 上手极慢
- 类型和边界不清
- 状态流难推理
- 测试无法提供安全感
那问题就不是“技术债有点多”。
而是系统的可变更性已经严重下降。
大型重构真正想恢复的，就是这部分能力。
为什么“重构不是重写”这句话仍然值得反复强调
因为几乎每一代前端团队都会重复踩这个坑。
一旦看到旧系统很乱，团队就容易产生一个直觉：
干脆重来。
问题在于，重写往往把两个高风险动作叠在一起了：
- 重建功能
- 重建系统
而大型重构最稳妥的原则通常是：
渐进、可逆、可度量。
这三个词比“先进”重要得多。
什么情况下大型重构是合理的
只有当系统已经明显影响持续交付时，大型重构才有成立空间。
比较常见的信号包括：
- 关键路径改动越来越慢
- Bug 修复引发回归越来越多
- 类型与模块边界过度混乱
- 团队不敢删代码
- 依赖升级成本过高
- 新能力无法进入现有架构
如果只是觉得代码不够优雅，通常还不到发起大型重构的时候。
为什么重构策略首先是风险管理策略
很多人会把大型重构理解成“代码层清理计划”。
其实更准确的看法是：
它首先是一套风险管理方案。
因为你真正要控制的是：
- 业务中断风险
- 回归风险
- 双线维护风险
- 团队疲劳风险
- 迁移中半途而废的风险
所以一个成熟的重构方案，往往最先写清楚的不是最终架构图。
而是：
- 每一步如何落地
- 每一步怎么回滚
- 每一步如何验证收益
Strangler Fig 为什么在重构里这么重要
Strangler Fig 的价值，不是它名字好记。
而是它提供了一种特别适合大型系统演进的思路：
新系统不是一次把旧系统替掉，而是逐步包裹、逐步接管、逐步替换。
这种方式的最大优点是：
- 你可以持续交付
- 你可以分阶段判断方向是否正确
- 你可以把风险拆开，而不是一次性全部承担
这比“统一切换日”要稳健得多。
前端里的 Strangler Fig 通常长什么样
在前端领域，它很常见地表现为：
- 新页面走新架构，旧页面暂时保留
- 新模块先接入新状态层，旧模块逐步迁移
- 新设计系统覆盖新区域，旧样式区慢慢被吞掉
- 新路由进入
app/，旧路由保留在pages/
也就是说，Strangler Fig 在前端里通常不是某个单独技术。
它更像一种迁移组织方式。
为什么“可逆”两个字非常关键
很多重构方案一旦推进，就变得很难回头。
这是非常危险的。
因为真正的生产系统里，团队不可能保证每个判断都对。
所以更成熟的重构设计通常会主动保留：
- Feature Flag
- 双实现并存期
- 限定切换范围
- 回滚路径
如果一个方案没有回退空间，它就更像赌博，而不是工程。
为什么 Feature Flag 在大型重构里意义很大
Feature Flag 不只是产品实验工具。
在重构里，它最大的价值是：
让新旧实现可以并存、切换和灰度。
这会直接降低：
- 一次性全量切换风险
- 事故恢复成本
- 团队对上线的心理压力
但也要注意，Flag 本身不是白送的。
Flag 多了，也会带来：
- 状态复杂度
- 代码分支增多
- 长期清理压力
所以成熟团队会把它看成临时脚手架，而不是永久结构。
并行运行为什么很有价值
很多重构最怕的不是“新实现起不来”。
而是“新实现看起来没问题，但行为 subtly 变了”。
这时并行运行就会很有价值。
例如：
- 新旧实现同时计算结果
- 后台比对输出差异
- 先不切真实用户流量
这种方式虽然会增加短期复杂度。
但它常常能把大事故变成可控问题。
Codemods 的价值不只是省时间
很多人提到 codemod，会把它理解成：
自动批量改代码。
这当然是它最直观的价值。
但更深一层地看，codemod 的意义还在于：
它能把“反复的人肉机械改动”变成“确定性的结构变换”。
这在大型重构里非常重要。
因为一旦改动量大到一定程度，人肉一致性就会明显下降。
所以 codemod 不只是效率工具。
它也是一致性工具。
什么类型的重构特别适合 Codemods
比较适合自动化的通常包括：
- API 调用签名变化
- import 路径迁移
- 生命周期到 Hook 的部分模式迁移
- JS 到 TS 的一部分批量替换
- 组件属性命名统一
不适合盲目自动化的通常是：
- 强业务语义判断
- 状态归属重构
- 组件职责重新设计
这说明 codemod 很强，但它处理的是“结构替换”，不是“架构理解”。
为什么测试不能在重构后再补
很多团队会说：
先改，改完再补测试。
对大型重构来说，这往往太晚了。
因为测试在这里承担的不是“锦上添花”功能。
而是迁移安全网。
如果重构前没有足够的行为基线，你连“是不是改坏了”都很难确定。
所以成熟的策略往往是：
先补关键路径测试，再做高风险重构。
不需要一口气补满。
但必须先把最重要的行为路径保护起来。
为什么重构最怕目标太多
这是大型重构失败的高频原因。
团队常常会想：
- 既然要重构，不如顺便换框架
- 既然要换框架，不如顺便重做状态管理
- 既然重做状态管理，不如顺便上设计系统
最后结果是：
目标一多，边界就失控。
成熟团队会尽量把目标压缩成一句最核心的话。
例如：
- 提高模块边界清晰度
- 降低特定区域改动成本
- 完成某层基础设施迁移
而不是把一切愿望绑成一个大计划。
中国互联网语境里为什么大型重构经常压力更大
中国互联网产品常常面临：
- 业务节奏快
- 发布频率高
- 多团队并行
- 活动和临时需求很多
这会让大型重构特别容易被打断。
所以在中国语境下，能不能把重构做成“可碎片推进”的工程，往往比架构理念本身更关键。
这也是为什么：
- 小步迁移
- Feature Flag
- 灰度切换
- 分模块落地
会比“大计划统一推进”更现实。
海外语境里为什么更常把重构和 maintainability 绑定在一起
海外很多工程团队，尤其 SaaS 和平台型组织，更习惯用：
- maintainability
- readability
- system health
- technical leverage
这样的语言去描述重构。
这意味着他们在叙事上更容易强调：
- 系统长期可维护性
- 架构边界清晰
- 代码健康度
这也提醒我们，重构不该只讲技术“升级感”。
它更应该讲系统健康度。
面试或技术分享里怎么讲更成熟
一个更成熟的表达可以是：
大型重构的目标不是把代码变新，而是恢复系统的可变更性。真正好的重构策略通常是渐进、可逆、低风险的，会优先围绕 Strangler Fig、小批量替换、测试基线、Feature Flag 和 Codemods 去设计，而不是一开始就押注全量重写。
如果一个重构计划说不清每一步怎么验证、怎么回滚、怎么控制爆炸半径，那它通常还只是技术愿望，不算成熟方案。
实践建议
实践一：给一个真实重构任务写“最小推进路径”
不要写最终蓝图。
只写：
- 第一步做什么
- 成功标志是什么
- 怎么回滚
实践二：做一个小型 codemod
哪怕只是统一某个 import 或属性名，也能帮助你建立“结构变换自动化”的思维。
实践三：为一次重构补 3 条关键路径测试
先保护最重要的行为，再动代码。
这个顺序会直接改变你对重构风险的理解。