Files
gitea-pr-review/docs/ideas/意见整理skill.md
T

2.7 KiB

我想要编写一个 skill, 来对杂乱的 PR review 意见进行分类. 我初步决定把审阅者的 comment 分为以下几类:

  1. 问题 (question): 审阅者不理解某处代码的意图, 提出了需要得到解释的问题
  2. 补充 (supplement): 审阅者理解了某处代码, 但觉得它可能不容易被其他人理解, 因此补充了一些信息
  3. 修正 (request-for-change): 审阅者认为此处代码或设计可能存在缺陷, 需要修改

我又想把修改按照两个维度分类: 改动性质 和 必要性. 改动大小可以分为:

  1. 局部修改 (local): 可以在 30s 内完成的小任务. 如标识符重命名, 换用某种语法糖, 调整空行和顺序, 调整模块层次结构.
  2. 实现方式修改 (implement): 涉及业务流程的代码变动. 如修改同步点, 修改数据库读写事务, 修改某个功能的实现方式. 这种层次的修改一般需要补充对应的测试以表明旧方式的错误之处.
  3. API 设计修改 (api-change): 涉及某些使用较为广泛 (对内使用超过四处或对外的) 接口的修改, 一般需要改动对应的测试使其适应新接口.
  4. 需求修改 (requirement-change): 审阅者发现某些或是全部代码解决的需求就是不合理的, 需要重新进行需求评估.

必要性可以分为:

  1. 小建议 (nice-to-have): 在完成了所有其他 request 之后才考虑进行的修改. 比如一些内容空泛的建议, 或是增加小包装/小辅助函数.
  2. 应当修复 (should-fix): 除非有合理理由, 否则应该解决此问题. 合理的理由举例: "该问题可能并不会被触发" 的证明; "我们知道该问题触发了会有影响, 但不会很大" 的说明; 留待下一个 PR 实现.
  3. 必须修复 (must-fix): 不解决该问题, 此 PR 绝不能被合并.

这个 skill 应该对本项目提取出的 pr review 意见 markdown 里非结构化的, 比较随意的, 混杂了上述所有种类的审阅者意见进行整理, 为每条或一组相关意见整理为按上述体系分类好的 "意见", 格式类似于:

> Question 
> <审阅者> 请求对 xxx (做法/概念/数据结构) 做出解释.
... (相关原始审核意见)
> Supplement
> <审阅者> 对 xxx 做了补充说明: (...大意). 考虑是否补充到代码注释或文档之中.
... (相关原始审核意见)
> Request-for-change, local, nice-to-have
> <审阅者> 要求做 xxx.
... (相关原始审核意见)
> Request-for-change, implement, should-fix
> <审阅者> 认为 (某某实现方式) (在某某情况下) (可能/必定) 会出现 (某某问题) (, 建议改为某某)
... (相关原始审核意见)

最后的输出应该是一个一条条的 markdown 文档.