现象：Reviewer 不说原因
Reviewer 往往直接说“把 A 改成 B”，却不告诉 Author 为什么要这么改。
这会导致：
- Author 不理解修改意图，盲目修改。
- 增加了不必要的沟通成本。
- 新手 Reviewer 不知道该如何写出高质量的评论。
现状调查
作者从 Google 的开源项目中爬取了 Gerrit 上的数据，经过人工标注发现了几个有趣的现象：
- 几乎一半的评论只有 Suggestion，完全没有 Explanation。
- 如果 Reviewer 写了解释，79% 的情况下都会伴随着具体的修改建议。单纯“为了解释而解释”的情况很少。
Explanation – 7 种模式
- Rule or Principle (引用规则)：比如“根据谷歌代码规范，这里不能这么写”。
- Similar Examples (类比)：给出一个类似的例子，“你看某某文件里也是这么处理的”。
- Test Scenario (测试场景)：描述一个会导致失败的场景，“如果输入为空，这里会崩”。
- Future Implications (未来影响)：比较高阶，“这样写以后扩展新功能会很麻烦”。
- Personal Preference (个人偏好)：“我觉得那个名字有点怪”（比较主观）。
- Stating an Issue (指出问题)：最常见的，直接说“这里有内存泄漏”。
- Benefit of Suggestion (强调收益)：画大饼，“这样改代码可读性会更好”。
Reviewers 专家 vs 新手 的差距
论文对比了 Experienced Reviewers 和 Novice Reviewers 的行为差异：
- 频率上，新手和专家写解释的频率差不多（这一点比较反直觉）。
- 类型上，
- 专家会使用更多样化的解释类型。
- 专家更喜欢使用 Category 4 (Future Implications) 和 Category 1 (Rules)。
- 新手比较依赖 Category 6 (指出当前代码的问题)。
既然 Reviewer 懒得写解释，能不能让 ChatGPT 帮 Author 生成？
作者设计了一个实验：给 ChatGPT 代码片段和一句简短的评论，让它扩写成特定类型的解释。
- 发现 “Base + Line” 的 Prompt 效果最好（输入评论 + 代码行内容）。输入 Commit Message 反而可能引入噪声。
- ChatGPT 大部分情况下能生成正确类型且内容准确的解释。
- 作者开发了一个 Demo 工具，Author 如果看不懂评论，可以点一个按钮：“请用‘类似案例’的方式给我解释一下这条评论”，ChatGPT 就会生成对应的解释。
启发
- 感觉这篇论文挺万金油的，可以引用。
0 条评论