把两百行函数拆成可测试小步
收录 2026-10-28
面对一个谁都不敢动的长函数，先识别隐式状态与副作用，再拆成边界清晰、可单独测试的步骤。
你是一名做过多次大重构的资深工程师。我有个两百多行的长函数，没人敢动，请帮我把它拆成可测试的小步骤。 [函数代码]：完整粘贴，包含它依赖的全局变量 [调用方]：谁在什么场景调用它 [现有测试]：有几个、覆盖了什么 [不能改变的行为]：对外返回值、日志格式、调用时序 输出结构： 1. 行为快照：输入到输出，以及所有副作用（写库、日志、发请求、读时间、随机数） 2. 拆分方案：每一步的职责、入参、返回、可单独测试的点，最多 5 步 3. 迁移顺序：每步都能独立提交并回滚，标明哪步风险最高 4. 需要新增的最小测试用例：每条写清输入与断言 验收标准：拆分后对外行为完全不变；每步可脱离上下文单独调用；不引入新框架或新依赖；涉及副作用的步骤必须显式传参而不是读全局。无法确认的行为单独列出，不要替我决定。
本站原创
中文原文
复制前替换这些占位符 4
把方括号里的内容换成你的具体信息，替换后再粘贴给 AI。
[函数代码][调用方][现有测试][不能改变的行为]
使用建议
没有现成测试时别直接重构，先让它生成行为快照用例，否则拆完很难证明行为没变。
可以这样改
- 要求它先复述需求与约束，确认无误再写代码。
- 让它给出最小改动 + 回滚方式，而不是整文件重写。
交付物（这次应拿到什么）
- 可运行的最小改动（含直接可用的代码块）
- 影响面清单：改了哪些文件、哪些调用点要跟着改
常见错法
- 一次让它改十个文件，最后分不清哪处改动导致了新问题。
- 只贴报错不贴代码和版本，拿到无法落地的修法。
输出验收（怎么判断能用）
- 改动可运行、可回滚，且没顺手改无关代码。
- 边界条件（空值、超长、并发）有说明或测试。
适用场景与注意
- 适合：让它先复述需求和约束，再给最小可运行改动。
- 注意：贴报错时同时给版本号与最小复现，否则它容易给出看似合理但不适配的写法。