Files
2026Technology-Competition/tests/measure/performance-comparison.md
T
范智鹏 e9762bfbe1 test: 目录对齐赛道二成果物规范(tests/ 迁移+实验报告+提效测量脚本)
- src/test 迁移至根目录 tests/(16 测试 + fixtures/manual),导入改为 ../src/
- 新增 tsconfig.test.json 独立编译测试;.vscode-test.mjs / package.json / .gitignore 同步
- 新增 tests/test-execution-log.md、tests/test-cases.md(116 用例清单)
- 新增 tests/measure/measure-review-time.mjs + performance-comparison.md(提效测量)
- 重命名 3 个中文报告文件为 demo-*-coverage-report.md
- git rm --cached 解除 vsix 跟踪;README 标注演示视频进行中
2026-08-26 19:17:44 +08:00

2.1 KiB
Raw Blame History

提效对比报告(基线 vs 提效后)

一、测量方法

场景:对给定样例代码进行代码规范检查,比较两种方式的耗时与产出。

  • 基线(人工审查):由人工阅读样例代码并列出规范问题(耗时依赖个人经验,需实测采集)。
  • 提效后(Code Purifier 插件静态分析链路):使用与插件内置配置逐字一致的 ESLint / Stylelint 引擎对 data/demo-*/src/* 执行静态分析,计时(可复现:node tests/measure/measure-review-time.mjs)。

测量脚本只产插件侧耗时;人工基线需实测后手动填入下方表格,原始记录需保留(时间、审查人、发现数)。

二、对比维度

维度 基线(人工审查) 提效后(插件静态分析)
审查耗时 待实测填入 见下表(脚本产出)
发现规范问题数 待实测填入 脚本产出诊断数
覆盖率口径 依赖个人经验 内置配置规则全覆盖(demo 实测 100%)
可重复性 低(因人而异) 高(同配置逐字可复现)

三、插件侧实测数据(脚本产出)

运行:node tests/measure/measure-review-time.mjs,结果另存 tests/measure/results/measure-results.json。 实测日期:2026-08-26Node.js v24.16.0。

目标 文件数 诊断数 耗时
demo-eslint 6 294 192.2ms
demo-stylelint 2 115 2106.7ms
合计 8 409 2298.9ms

四、人工基线(待实测)

请按以下步骤实测后填写,并保留原始记录:

  1. data/demo-eslint/src/common.js(约 12KB)为样例;
  2. 审查人逐行阅读,列出发现的规范问题(命名/风格/潜在 bug 等),记录耗时;
  3. 多人重复(建议 ≥3 人)取平均,填入下表。
审查人 样例 耗时 发现问题数 日期
待填 common.js 待填 待填 待填

五、提效结论(待数据完备后填写)

待人工基线数据填入后,据此计算提效幅度并总结结论。