第 8 章 配合 Code Review
维护者从六个维度审查你的 PR，提前照此自检。
8.1 六个审查维度
维护者据此逐项检查，你提 PR 前照此自检。六维定义以《管理员层手册》第 2.2 节为准，下面是开发者视角的自检要点：
- 功能正确性：实现预期功能；边界情况与错误处理完备。
- 算法正确性：逻辑正确；数值精度可靠；无死循环、无无限递归。
- 命名规范：命名符合约定，不用
a、temp、data1；注释与行为一致。 - 可复现性：参数无未说明的硬编码；随机种子已固定或已说明；用相对路径；含或引用实验记录。
- 文档完整性：新增函数有关键注释；同步更新 README、文档、CHANGELOG。
- 代码保密合规：无硬编码密码 / 密钥 / 内部 IP；未误提交数据文件；无外部仓库地址。
8.2 如何编写便于审查的代码
- 原子提交，一个 commit 只做一件事。
- 一个 PR 只做一个完整功能，标题与 subject 一致，模板填全。
- 涉及实验参数或数据时附实验记录链接。
- 自测通过后再提 PR，附最小复现步骤或测试命令。
8.3 收到修改意见后
- 在原功能分支补 commit，不另开 PR，也不在
main上改。 - 逐条回应：说明改了什么、为何这样改；有不同意见就讨论，不要默默忽略。
- 重新推送后自动追加到原 PR，等待复审。
8.4 参与讨论
可评论他人 PR、提建议，但最终签字权仅归维护者。互审时，你可作为另一名成员为同组成员的 PR 提修改意见。
维护者侧操作（签字、六维落表、合入、清理）见《管理员层手册》第 2 章。
8.5 练手
在自己的 Fork 里，为第 2 / 6 章那个 PR 走一遍「提意见 → 原分支补改 → 自审合并」，把双角色练完整。
- 打开该 PR，先按 8.1 的六维逐项自检，再在 PR 里写一条具体的 review 意见（例如「成员卡片的『方向』写得更具体些」）。
- 回到原功能分支按意见改，不另开分支或 PR：
git checkout feature/add-<name>
# 按意见修改 members/<name>.md
python scripts/check-members.py members/<name>.md
git add members/<name>.md
git commit -m "fix(members): 补全<你的名字>成员卡片字段"
git push新 commit 会自动追加到原 PR。
- 在 PR 里逐条回应每条意见（含你写给自己那条）：说明改了什么、为何这样改。
- 确认无误后自己 Approve 并点 Merge。
真实项目组里签字权归维护者、需他人审批；练手仓库为了让你一个人完整体验双角色，才由你自己 Approve、自己合并。