生成代码怎么评审
生成代码（ORM 迁移、protobuf 产物、模板渲染结果）不该逐行看实现，而应看输入与生成规则：源头定义是否正确、生成命令与生成器版本是什么、差异模式是否符合预期。判断标准是可重现——重新生成一遍，产物应当与提交内容完全一致。
基本信息
| 评审重点 | 源头定义、生成命令与版本、差异模式 |
|---|---|
| 源头文件 | schema、proto 文件、模板 |
| 可重现验证 | 重新生成后确认与提交内容一致 |
| 目录约定 | 生成物与手写代码分开放置，避免互相覆盖 |
典型使用场景
- 数据库迁移脚本：核对 schema 改动是否确有其意
- 接口定义变更：先看 proto 文件，产物差异顺手检查
- 模板渲染结果：确认模板改动范围，再看产物
- 生成器升级：升级带来的大范围差异应单独提交
- 发现产物被手工改过：要求回到源头修改后重新生成
评审生成代码的四个动作
- 先看源头文件是否合理
- 确认生成命令与生成器版本
- 扫描差异模式，找出异常的删除与重命名
- 重新生成一遍，验证产物可重现
可重现验证
可重现验证
# 重新生成之后确认工作区没有变化
git status --porcelain
# 若产物与提交不一致，说明生成器版本或参数不同
protoc --version差异模式与含义
| 差异模式 | 可能原因 |
|---|---|
| 大量重命名 | 生成器版本升级或命名规则调整 |
| 范围之外的删除 | 源头定义被误删，属于阻断项 |
| 同一文件反复抖动 | 生成顺序或时间戳被写进了产物 |
| 只有少量新增 | 常见的正常增量 |
手改生成产物是坑：下次生成就被覆盖，评审时应该要求回到源头去改。
生成器升级与业务改动混在一次提交：差异巨大，问题定位成本陡增。