注：本文仅关注 Code Review 的实行，不讨论 “为什么要 Code Review” 或 “Code Review 是否有价值” 这类话题。
通过 Code Review 来保证项目代码质量、提高团队的技术水平，已经是很多公司的常规操作，大多数人也已经认可了进行 Code Review 的必要性。然而，现实是这样的：
”伴随着号召和口号，大家热情高涨，一顿操作花式输出，目指用洞察世界的双眼来拯救这个腐朽的Repo，而待多巴胺褪去，热情难以为继，全都恢复成了没有感情的 Coder，三天打鱼两天晒网，再到最后完全流于形式，直至热情再一次被唤醒……“
陷入循环中，我们不禁要呐喊：
“为什么Code Review这么麻烦这么累”
1. 错的不是我，是这个PR
Code Review 会让人觉得麻烦、代码看起来很累，很多情况下确实是因为这个 PR 并不易于 Review，本身存在一些问题：
• PR 太大：动辄几千行代码、几十个文件修改，打开一看就怕了怕了，没有做好心理建设、备好两三个小时的空闲时间谁敢 Review，告辞告辞；
• PR 要做事的太多：东边儿全局修改了变量名，西边儿重构了公用方法，南边儿调整了页面样式，北边儿还顺便修了一个陈年老 bug……嚯，好家伙，一个迭代的需求一个 PR 就提上来了，也就 Author 勉强在当天还能搞清楚哪段是哪段，Reviewer 一路看下来就得怀疑人生；
• PR 没有上下文：“为什么要删除这段代码？为什么要加这么多分支逻辑？这么多类似的方法真的是必须的吗？这种场景没有判断，是遗漏了还是业务需求？”你是否有很多问号？？？总会有很多问题，在缺乏上下文时，是很难给出解答的，不写任何 Description，想要让 Reviewer 自己主动去搞清楚业务背景实在是不厚道，所以也别怪没人肯 Review 了；
• PR 代码质量太差：不遵守既定规范、格式乱七八糟、命名天马行空、逻辑晦涩难懂，整篇代码毫无“可读性”可言，对于这种 PR，Review 两眼是情分，直接Request Change才是本分。
2. 即使我有错，也是有原因的
如果，PR 确实不存在问题，代码整洁、逻辑清晰，Description 安排地明明白白，却还是没能得到回应，那的确应该是 Reviewer 的问题，不过为他们考虑考虑，可能也是有原因的：
• 工作量过于饱和：再简洁明了的 PR，Review 起来还是需要时间的，忙得已经没有喝水的时间，哪还有工夫去做 Code Review；
• 道不同不相为谋：你有你的原则，我有我的风格，既然谁也说服不了谁，那就这样吧；
• 技术领域不同：“我说另请高明吧，我实在也不是谦虚，我一个后端开发怎么就点进前端PR了呢？”；
• 看不出问题：虽然说起来有点尴尬，但确实是一个很普遍的情况，没有掌握方法、相关技术储备不足、Review 角度不同等等，一篇 PR 读下来，似乎觉得哪里不对，又似乎也有道理，Comment 憋不出来、Approve 又不放心，那就跳过跳过，等其他大牛出手吧。
那么，有这么多严峻的问题存在，你看，我们还有机会吗？
问得好！还记得文章的标题吗：
“我们不用很麻烦很累就可以 Code Review”
1. 作为 Author
• PR 尽可能小
○ 创建 Draft PR：便于获得早期反馈，避免在代码成型后出现大规模的修改返工
○ PR 只关注一件事：降低阅读 PR 时的认知成本、更易于确定合理的 Assignee、Rollback 的可行性更高、开发更具计划性
○ 严格执行 Rebase：避免引入不必要的修改或造成 Review 的返工
• 添加关键的上下文
○ 不可缺少的 Description（必要时可尝试使用Github PR template辅助规范化），可以主要关注以下几点：
▪ 这段代码改动的目的是？（通常情况下提供需求 Ticket 标题及链接即可）
▪ 能预料可能会提出的问题，请提前说明（如存在多种近似解决方案，选择当前方案的原因）
▪ （若存在）特定逻辑需要特定 Reviewer 关注，请提前说明
▪ （若存在）批量修改，请提前说明
▪ （若存在）UI 修改，请提供屏幕截图或可查看到实际效果的链接
○ 易于理解的 Commit Message，严厉抵制 ”fix bug“ 这种偷懒 message
○ 代码中添加必要的注释
• Assign给正确的人
○ Assign组内成员
○ 期望能给出反馈的人:
▪ 擅长/熟识该业务领域的人；
▪ 擅长/熟识该技术领域的人；
○ 期望能知晓该 PR 的人：
▪ 会受到该代码改动影响的人；
▪ 近期正在学习该业务/技术领域的人；
• 收到Comment及时跟进
○ 修改后及时回复 comment 或 refresh assignee，不要指望其他人能一直蹲守你的更新或修改
○ 出现意见分歧，避免过度依赖 Comment 交流，线下沟通优先，其次是 IM
○ 若因时间或计划问题无法在当前 PR 中完成修改，达成一致后创建 Tech Debt Ticket 备忘
○ 尽可能避免在已经Approve的PR上进行无关修改，以免给Reviewer造成不必要的重复工作
一句话总结：对自己提出的每一个 PR 负责
2. 作为Reviewer
• 主动阅读 Description
○ 作为普通 Reviewer，有必要了解 PR 的上下文
○ 作为业务/技术领域相关者，有必要了解代码及逻辑变更情况
• 得当的 Comment
○ 表述简洁清晰无歧义
○ 通常应具有目的性：明确知道自己想要的回复是哪一种，是希望 Author 改正问题？补充上下文？解答疑惑？或是说明计划？目的不明的 Comment 只会造成不必要的反复沟通
○ 不仅可以指出问题，同样可以请教问题
○ 给出肯定或表扬的 Comment
○ 无需过于正式：Comment 的数量并不会用于反映工作量，因而任何形式不会对双方工作造成影响的 Comment 都是可行且值得鼓励的
• Comment 后及时跟进
○ 及时回复 Author 的追问
○ Author 修改后及时 Resolve 或 Approve
• 及时给出反馈
○ 根据实际情况，给出 Approve，Comment 或 Request Change
○ 谨慎给出 Approve：Review 代码后，若有足够把握，可以给出 Approve；若存在疑虑（不了解相关业务、底层逻辑），也应给出 Comment 表明 Review 完成，不应让 Author 无止尽的空等
• 不要成为 Blocker
○ 仅有的 Repo Code Owner、点名指定的 Reviewer（业务/技术领域相关者），必须要给出反馈
○ Request Change 的 Reviewer，必须要及时跟进
一句话总结：对自己给出的每一个 Comment 和 Approve 负责
3. 参与者应有的共识
• Code Review 的主要目的不应是为了发现 Bug，也不应是为了检查代码风格和规范
• Code Review 是沟通的一种形式，作用是相互的
• Code Review 时不要吝啬你的赞美之词
• Code Review 时不可固执己见
• Code Review 时应正面且友善
最后，
还有几句要说：
看到这儿大家应该都能感觉到，Author 要做的事情和 Reviewer 要做的事情基本都是相辅相成，两边缺一不可，说到底，推动 Code Review 需要整个 Team 甚至公司一起努力，但需要努力，并不意味着“不用很麻烦很累”是 Fake News，只要 Code Review 成为公司的一种文化、一种习惯，所有的一切都会变得理所当然，且有趣。
“卓派前端工作志，聚焦实用前端技术，让编程更有趣！”
前端技术组 @ 西安卓派科技 NEXT Trucking — 拉勾 | Boss | 知乎 | 掘金 | 简书
如果觉得本文对你有帮助的话，快来关注我们吧！
