代码审查文化与 PR 最佳实践

代码审查不是把关——它是团队共同学习、交接责任并保持高质量的方式。良好的审查文化能提升整个团队；糟糕的审查文化则会造成瓶颈和怨恨。

1）保持小规模（如果可以，控制在 400 行以内）。2）写清晰的描述：为什么改、改了什么、如何测试。3）关联工单。4）对于界面变更，添加截图或视频。5）请求审查者之前，先自行检查差异。

使用与提交相同的约定式前缀：feat: add user profile page、fix: handle 404 in fetch wrapper、refactor: extract Avatar component。许多团队会根据这些前缀生成变更日志。

大多数团队都会使用 PR 模板——将其安装到 .github/pull_request_template.md。

请求审查者之前，请逐行检查自己的差异。为不明显的设计选择添加解释性注释。您经常可以在别人发现问题之前，先发现自己的错误。

2000 行的 PR 很少能得到彻底审查。请拆分为：1）重构（不改变行为）；2）新增行为；3）界面润色。这样每个部分都更容易审查和回滚。

请用提问而不是命令来表达：“您觉得把它提取为钩子怎么样？”比“提取它”更好。区分必须修复项和可选改进项。请使用这些前缀：nit:、question:、blocker:。

“这让人困惑”不会告诉作者任何有用信息。“为了理解这个提前返回，我不得不读了 3 遍——我们可以提取一个守卫子句吗？”则能让作者明确下一步行动。

请积极评论巧妙的解决方案、良好的命名和有帮助的测试。这样可以鼓励这些模式，也能缓和其余反馈的语气。只受到批评的 PR 会让人感觉是在对立地交流。

Prettier 负责格式化。ESLint 负责代码风格。不要把审查时间浪费在制表符还是空格上。如果某条风格规则总是需要讨论，就把它编码到代码检查器中。

测试也是代码。请确保新增代码有测试。检查测试是否确实验证了正确的对象——许多测试即使代码已损坏也会通过，因为它们断言的是错误的对象。

请回应每条评论——即使只回复一个竖起大拇指的表情也可以。对于您不同意的建议，请提出异议（代码是您写的；您可能掌握额外背景）。将已解决的讨论串标记为已解决。如果范围发生变化，请更新 PR 描述。

请在一个工作日内完成审查。长期未更新的 PR 会失去背景信息——作者已经继续推进，分支也需要变基。大型 PR 如果搁置一周，最终总会变成痛苦的合并工作。

GitHub 的建议功能允许作者一键接受修复。这比在正文中写“将这一行改为 X”快得多。

在以下条件都满足时批准：代码正确、测试通过、您理解这项变更，并且合并是安全的。批准意味着您也对结果共同负责。不要走过场式地批准——如果您没有读过代码，请直接说明。

当您对某项代码的写法与作者不同，提供代码审查反馈时，推荐采取什么态度？

作者：提交小规模、描述清晰，并附有截图和测试的 PR。先进行自我审查。审查者：提供建设性的、以提问为主的反馈。区分阻塞项和细节问题。赞扬做得好的地方。跳过风格问题——交给工具处理。在一天内完成审查。只有在理解变更后才批准。PR 模板可以规范流程。审查是协作，而不是把关。