浏览 AI 知识库

重构前怎样固定现有行为，避免顺手改变业务逻辑

重构的前提是知道旧代码现在做什么。先用特征测试固定关键输入输出，再拆结构；业务规则要不要改，应当作为另一项明确决定。

沿完整工作流推进

前一阶段的可检查结果，是下一阶段的输入；中间证据不足时停在当前阶段。

沿一件真实任务走到底

准备重构折扣计算，代码没有测试；函数混合会员等级、优惠券和日期规则。开发者一边拆函数一边修“看起来不合理”的结果，业务行为悄悄改变。

本例材料

需要确认	本例内容
现有材料	现有生产样本 12 个已脱敏订单、当前函数输出和两条已知异常；本次只重构结构，不改规则。
不能越过的边界	先用特征测试固定当前可观察行为；已知异常单独记录，不在重构中顺手修；前后输出逐项比较。
要交付的结果	特征测试与前后差异报告

处理记录

当前阶段	实际处理
界定重构目标	写要改善的结构、可维护性或性能问题，以及明确不改变的外部行为。
捕获当前行为	为关键输入、边界、错误和副作用添加特征测试，哪怕当前结果不理想也先记录。
建立安全小步	一次只移动、重命名或抽取一种结构，保持每步可编译、可测试和可审查。
分开业务修复	发现真实 Bug 时单独记录和提交，先确认期望行为与负责人，不藏在重构中。
比较前后证据	运行相同测试、接口样例和性能基线，审查 diff 是否只涉及目标范围。

重构前后对照

项目	重构前证据	本轮动作	不变/变化
输入输出	订单 ID 17 返回总价 99	抽取 PriceCalculator	金额和舍入规则不变
错误	库存不足返回 409	移动错误类型和测试夹具	状态码和错误契约不变
副作用	创建一条审计记录	保留调用点并加特征测试	记录内容和顺序不变
真实 Bug	发现旧税率错误	单独开修复任务	不藏在重构提交里

数字和接口为示例；真实项目先捕获当前行为，再决定哪些有意变化需要单独审批。

最终输出

12 个订单形成黄金输入/输出，覆盖会员、券叠加、边界日期和空值。拆函数前后结果完全一致；已知异常仍作为跳过用例链接到独立任务。差异报告为 0 后才合并重构。

常见失败

验收方式

现有行为在改代码前已锁定重构与业务修复分开前后差异报告可复查目标结构和明确不变行为已写清关键输入、边界、错误和副作用有特征测试每一步可编译、可测试、可审查业务修复与结构重构分开记录前后测试、接口样例和性能基线均有比较结果

进一步核对

浏览器测试、定位器、等待和追踪方式以当前 Playwright 文档为准。

状态码只说明响应类别，根因还要结合请求、日志和上游链路判断。