重构是技术简历上很微妙的一类经历。写好了是能力证明，写不好会引出两个尴尬的联想：
第一个：这些烂代码是不是你自己写的？
第二个：重构完了到底好在哪，还是只是把代码挪了个地方？
要解决的就是这两个。
为什么重构经历容易写虚
因为重构的成果常常是「没有变化」：功能一模一样，用户无感，业务指标不动。
于是简历上只能写「重构了订单模块，提升了代码可维护性」。而「可维护性」是一个无法验证的词，面试官没法判断。
解决办法是：找出重构带来的可测量的变化。它一定存在，只是你没记。
四个必须交代的要素
一、重构前的问题是什么，而且要有数据。
不是「代码混乱」，而是「一个下单主流程的方法 1200 行、圈复杂度 87，改一个优惠逻辑平均要动 5 个文件，近半年该模块线上问题 9 次，其中 4 次是改 A 影响 B」。
这段数据是整条经历的地基。有了它，后面的一切才有意义。
二、你的判断和方案选择。
为什么这么拆，为什么不推倒重写，为什么先做这块而不是那块。这一层最能体现能力。
三、怎么保证不出事。
这是重构经历里最能区分水平的部分。任何有经验的面试官都知道，重构最大的风险是改出问题。你怎么控制这个风险，决定了你是不是真的做过大规模重构。
四、结果，用数字。
改前改后对照
改前：
- 负责订单模块的重构，优化了代码结构，提升了可维护性和可扩展性改后：
- 主导订单核心流程的重构。重构前：下单主方法 1200 行、圈复杂度 87，优惠、库存、支付三块逻辑交织；近半年该模块线上问题 9 次，其中 4 次属于改 A 影响 B；新人上手平均需要 3 周才敢独立改 - 方案：没有推倒重写（业务在迭代，停不下来）。按「识别边界 - 抽接口 - 逐块搬迁 - 删旧代码」分 4 个迭代做，每个迭代 2 周，优惠、库存、履约各抽成独立服务层，主流程只保留编排 - 保证不出事：先补了 76 条特征测试（对旧实现的输入输出做快照），重构后必须全绿；每块搬迁用开关双跑两周，线上同时跑新旧逻辑并对比结果，差异落日志人工核查，累计核查出 3 处旧逻辑的隐式行为（比如金额为 0 时跳过风控），这 3 处如果直接切会变成线上事故 - 结果：主方法降到 180 行、圈复杂度 19；同类线上问题在之后 6 个月内 1 次；优惠规则的改动从平均 5 个文件降到 1 个；新人第二周就能独立提优惠相关的改动改后的四段里，第三段（保证不出事）是最有分量的。特征测试、开关双跑、差异核查，这三样是真正做过重构的人才会提的，而且「核查出 3 处旧逻辑的隐式行为」这个细节，本身就是一个很好的面试话题。
关于「这些烂代码是不是你写的」
如果不是你写的，在描述里自然交代时间线就行：「接手时该模块……」「该模块由前团队开发，交接后……」。不需要强调，也不用回避。
如果确实是你早期写的，也有写法：
- 该模块由我在 2023 年初独立开发，当时为了赶上线选择了单体实现。到 2024 年业务复杂度上来后，这个选择的代价显现（改一处影响多处）。我主导了这次重构，把当初的取舍纠正过来这样写不但不减分，反而加分。它显示你能识别自己决策的代价并且负责到底。技术面试官对这种坦诚的评价通常很高。
面试官的三个必问，提前准备
「怎么说服团队和业务方给你时间做这件事？」
重构通常不产出业务价值，排期是最难的一关。答案要具体：是用「近半年 9 次线上问题」这类数据说服的，还是搭着某个大需求一起做的，还是拆成小块混在日常迭代里做的。
有一个务实的答案很受认可：不申请专门的重构排期，而是把重构拆进每个相关需求里，每次多花 20% 的时间搬迁一小块。
「怎么保证没改坏？」
前面说的特征测试、双跑、灰度、监控对比。没有这一套的重构，在面试官眼里是高风险行为。
「怎么衡量重构的收益？」
准备三类指标：代码指标（行数、复杂度、重复率）、质量指标（该模块的线上问题数、回归时长）、效率指标（同类需求的开发耗时、涉及文件数、新人上手时间）。
第三类最有说服力，因为它直接对应业务价值。
几种不建议的写法
写成技术选型炫技。「引入 DDD，按六边形架构重新设计」，如果说不出为什么这个业务需要这层抽象，会被认为是为了用而用。
只写代码指标。行数和复杂度降了，但线上问题和开发效率没变化，说明重构可能只是搬家。
没有风险控制。只写「重构了，效果很好」，面试官会默认你没做过真正有风险的重构。
规模夸大。「重构了整个系统」，追问一下发现是改了三个类，这种落差很伤。
如果你的重构规模很小
小规模也能写，只要四要素齐全。
- 把导出功能里的 6 个格式分支（各自 100 到 200 行、逻辑高度重复）抽象成模板方法 + 3 个策略实现，总行数从 940 降到 410；之后新增第 7 种格式只用写 60 行，耗时从预估 2 天降到 3 小时（新增 CSV 格式时实测）一条，四要素全有，末尾还带了一次真实验证。这比空泛地说「重构了整个系统」强得多。
最后
重构经历的价值不在于你动了多少代码，在于你能不能说清楚：问题是什么（有数据）、为什么这么改（有判断）、怎么不出事（有方法）、结果如何（有数字）。
四样齐全，它就是简历上最能被追问出深度的一段。
