重构三级分类体系：不同粒度的重构，对应完全不同的时间预算与风险承受方式

面对重构的悖论，可行的解法不是彻底放弃重构，也不是继续依赖”停下所有开发专门重构”这条走不通的路，而是把重构按影响范围拆成三个层级，分别配上完全不同的执行节奏和风险控制手段。第一级是模块内部重构（重命名变量/函数、提取内部函数、提取常量/变量），修改范围基本集中在一个地方，IDE的重构工具对这类操作支持得非常健壮，风险很低——这类重构应当随时进行，作为日常开发的一部分，每次耗时不应超过60秒，否则会拖累开发效率、进而被无穷无尽的开发需求淹没；简单的模块内重构（改个变量名）即使没有单元测试也基本可靠，如果要在快速完成和100%单元测试覆盖率之间选，宁可选快速完成。第二级是模块级别的重构（删除无用代码、移动函数到其他类、提取函数到新类、修改函数逻辑），会牵扯多个模块，IDE支持有限、偶尔会出莫名其妙的问题，这个阶段单元测试变成了必需品（一方面集成测试难以覆盖所有情况，另一方面”写不出单元测试的代码往往意味着设计糟糕”本身就是一条重要的诊断信号），还需要引入Adapter、Proxy、Wrapper这类过渡逻辑来控制变更的传导范围，每次实际修改的时间不应超过一天，超过就说明这次改动太大、需要控制节奏。第三级是工程级别的重构（修改工程结构、修改多个模块），影响范围最大，不建议依赖IDE（最多只用最简单的”移动”操作），单元测试在这个层级已经失去作用，需要依靠集成测试和冒烟测试来验证正确性，而且这类重构绝对不能和正常需求开发并行——因为代码冲突几乎无法避免，必须通知全员暂停开发、集中团队精英在两三天内突击完成，事后新需求都基于新代码继续开发。

结构图：

flowchart TB
    A["模块内部重构\n重命名/提取函数/提取常量"] --> A1["随时进行，是日常开发的一部分\n单次<60秒\nIDE支持健壮，风险低\n单元测试非必需"]
    B["模块级别重构\n删除无用代码/移动函数/提取新类/修改逻辑"] --> B1["需要单元测试(必需)\n需要过渡兼容层(Adapter/Proxy/Wrapper)\n单次实际修改<1天\n IDE支持有限，需谨慎"]
    C["工程级别重构\n修改工程结构/修改多模块"] --> C1["不能与任何其他任务并行\n需暂停全部开发2~3天突击\n单元测试失效，依赖集成测试+冒烟测试\nIDE只用简单移动操作"]
    A1 -.->|"日积月累的整理\n为模块级重构打基础"| B1
    B1 -.->|"局部优化的极限\n触及结构性问题时"| C1