Ren review

ren-review

启动必读

先 Read .ren-flow/attention.md 拿项目规范作为评审标尺。

这个技能干什么

独立于写代码的过程,以怀疑态度检查代码。和 ren-verify 分工清楚:

• ren-verify 问「能不能跑通、符不符合契约」
• ren-review 问「代码本身好不好 —— 规范、潜在 bug、架构、可维护性」

写代码的 AG 不该同时给自己做 review。ren-review 是另一双眼睛。

三种模式

模式	触发	做什么
评审	「review 一下这次改动」	检查一次具体改动(diff / 几个文件)
审计	「扫一下这个模块有什么问题」	主动扫一段代码 / 整个模块,列问题清单
接收评审	「收到 review 意见了」「别人说我代码有问题」	处理别人对你代码的意见,验证后再决定采纳

评审 / 审计走下面五个维度;接收评审走「接收评审模式」一节。

评审五个维度

逐个维度过,不要混在一起扫:

1. 规范合规 —— 对照 attention.md:命名、分层、各栈约定、日志 / 注释规矩、易错点清单。
2. 潜在 bug —— 边界条件、空 / null、并发、异常路径、资源释放、类型陷阱。问「什么输入会让它崩」。
3. 架构分层 —— 依赖方向对不对、职责有没有放错层、有没有绕过该走的边界。
4. 可维护性 —— 重复代码、过度抽象、命名词不达意、文件偏胖、隐藏耦合、长参数列表(方法参数偏多,经验阈值 >3 个 / 对外 API 直接平铺参数 → 应提取成 Request 类;具体阈值以项目 attention.md 各栈约定为准)。
   • 长参数列表要逐方法扫,别漏:① 跨多行的签名(单行 grep 看不全);② private 助手方法;③ 多个同签名方法(应抽一个共享 Request)。「和已有遗留多参方法保持一致」不算豁免 —— 遗留是债不是模式,照标。
5. 资源与性能 —— 数据访问层高频病灶,改动碰到 DB / 缓存 / 循环 / 异步时逐条扫:
   • 重复访问:调用链上游已查出的对象下游再查一遍;同一方法多次开连接 / 重复查同一条数据;查询条件语义重复
   • 查询写法:全量字段查询(该用投影);已知主键 / 唯一键却不带进条件;过滤 / 排序未命中索引;列表无分页无上限;恒真条件(where(true) / 1=1 式)
   • 循环与批量:循环内逐条调 DB / Redis / 外部接口(N+1,应收集 key 批量取);循环调「查单条」凑多条
   • 缓存:无空值缓存防穿透;缓存整个对象而非所需字段;该按筛选条件 + 分页缓存却全量缓存;key 冗长无分层
   • 异常与日志:catch 吞异常无日志;热路径打非必要调试日志
   • 异步与集合:fire-and-forget / 同步阻塞;列表转字典 key 类型不一致或重复;同一集合按不同条件遍历多次;惰性序列重复枚举未物化
   • 其他:魔法值未收敛成枚举 / 常量;事务里夹纯查询(事务只留必要写操作)

输出格式

按严重度分级列清单,每条要可定位、可执行:

## 评审结论:{通过 / 有阻塞问题 / 建议修改}

### 🔴 必须修(阻塞)
- `file:line` —— {问题} —— {为什么是问题} —— {建议怎么改}

### 🟡 建议修
- `file:line` —— ...

### 🟢 可选 / 风格
- ...

• 每条指明 file:line,不写「某些地方」。
• 说清为什么是问题,不只说「这里不好」。
• 区分「确定的 bug」和「我的偏好」—— 后者标清楚,别用规范的语气压偏好。

审计模式补充

主动扫一个模块时:只列清单,不直接修。修不修、先修哪个由用户决定。清单里标出每个问题的影响面和修复成本,帮用户排优先级。

接收评审模式

收到别人 / PR / 工具对你代码的意见时,流程是 读 → 验证 → 评估 → 回应:

1. 读完再动 —— 所有意见先读完,不在读到一半就开始改。
2. 验证正确性 —— 实施任何改动之前先验证意见对不对:跑相关测试、看实际代码路径、确认问题能否复现。意见与运行环境不符的(教科书正确 ≠ 当前架构正确),用证据反驳,不默默接受。
3. 评估价值 —— 每条过四问:描述准不准?这个改动真的需要吗(YAGNI)?实施会引入新风险吗?提意见的人对这个代码库熟不熟?
4. 逐条回应 —— 接受并实施(说怎么改)/ 接受但换个实现(说为什么)/ 拒绝(附验证证据或技术理由)。

禁止虚假顺从:不要用「你说得对」「好建议」「感谢指出」这类话开头 —— 它会让你在没验证的情况下接受错误建议。先验证,再回应。

实施通过评估的改动后重新跑测试确认无回归。确定的 bug 转 ren-fix,结构性建议转 ren-refactor。

与其他技能的边界

• 不修代码 —— 列问题,用户决定后回 ren-build(规范问题)、ren-fix(确定的 bug)、ren-refactor(结构 / 性能)
• 本技能定位日常 / 小改动的轻量评审;改动大或提交前总审,超出这个定位时,转项目声明的重型评审技能(若 attention.md 声明了)

退出条件

• 五个维度都过了(评审模式)
• 每条问题可定位到 file:line,说清了为什么是问题
• 区分了「确定 bug / 建议 / 偏好」
• 给了明确结论(通过 / 有阻塞 / 建议修改)
• 接收评审模式:每条意见都先验证再回应,无虚假顺从式回复

容易踩的坑

• 把偏好当规范压人 —— 偏好要标清楚
• 「这里写得不好」不说为什么、不给位置 —— 无法执行
• 审计模式顺手就改 —— 只列清单,用户拍板
• 只扫规范不查潜在 bug,或反之 —— 五个维度都要过
• 评审写代码的人自己的代码 —— 失去独立性