有些团队里 Code Review 处于开发流程的边缘位置，有些团队 Code Review 处于代码编写到部署的必经部分。对于我们来说，Code Review 是代码编写到部署的必经部分，所有代码都必须经过 Review 才能 merge。
Code Review 的几点实用性建议：
- 对事不对人。大家是同事，在一个团队工作和气很重要。不要在 Code Review 中说“你写的什么垃圾东西这种话”，你可以说“这个变量名不好理解，咱们换成巴拉巴拉是不是更好”。
2. 每个 Review 至少给一条正面评价。Code Review 本意是改善代码质量，增强团队成员之间的沟通，但是我一提交代码就有人说我写的垃圾，这很打击自信心啊，也不利于团队成员和平相处。代码有问题，指出问题是必须的，要实事求是，但是有的时候也需要给队友一点鼓励，例如简单的 或者“赞一个”我都很开心了。
3. 保证发布的代码和评审意见的可读性。大家都是程序员，你提交代码的时候，在符合团队风格的同时，把代码弄的好看点，如果你明确自己这个代码哪个地方不足，Highlight 出来让大家给意见。如果你是来 Review 代码的，把意见写的通顺点，评论有条理一些。对反引号 (`) 嵌入代码或三个反引号 (```) 写代码块，这样看的舒服得多，效率也高。
4. 用工具进行基础问题的自动化检查。用 Tab 还是空格，用两个空格还是四个空格，函数后面怎么换行等基础问题检查，可以使用 eslint 和Rubocop 等类似的工具进行，团队成员应该把更多精力放在代码规范，代码性能优化等地方。
5. 全员参加 Code Review，并设定各部分负责人。扩大 Code Review 参与面，参与不是说一定去审核别人的代码，可以是代码被审核，也可以是看别人审核意见，这都是学习的过程。并且每部分设定负责人，该负责人对这部分代码质量负责，负责人需要是资深工程师。全员参与 Code Review 可以让团队成员更快的成长，新人在看大佬 Review 代码的过程就能学到很多。
6. 每个代码 PR 内容一定要少。Code Review 效果和质量与 PR 代码量成反比，你一下提交这么多代码，我今天还下不下班了？ 我女朋友你帮我陪？每次 PR 代码量小一些，看起来速度快，又不至于失去耐心，这样才能达到 Code Review 的效果，所以要经常进行 Code Review，但是每个 PR 代码量要少。我建议要少于 300 行/PR。
7. 在写新代码之前，先 Review 掉需要评审的代码。你让我去 Review 一周前的代码？我还得把思维和项目进度切换到一周前？大家肯定不愿意，所以要形成规定，写新代码之前先把旧的 Review 掉，提交 PR 的时候也保证代码量小，这样 Review 起来不需要大块时间，改起来也快。不能因为 Code Review 大幅耽误项目进度，进度是全团队的事，不是某个人的事。
8. 如果你有更好的方案，尽管提出来。在 Code Review 中经常会发现写的不好的地方，如果你有更好的方法，欢迎提出来！首先能改进这个 PR 的代码，其次能体现你的能力，团队应该定期对这种提出好的解决方案的同事进行奖励。
9. 不要在 review 中讨论需求，review 就是 review。不要在 Code Review 里搞别的，有需要就另安排时间进行，要明确 Code Review 是完善代码，不是需求和功能讨论，始终要以代码质量为中心。
以上就是给大家代码审查的几点意见，既可以帮助你了解什么是代码审查，如何做代码审查，也可以帮你明确代码审查应该注意什么，准备什么。
推荐一些 Code Review 工具，可以了解一下：
- Crucible：Atlassian 内部代码审查工具；
- Gerrit：Google 开源的 git 代码审查工具；
- GitHub：程序员应该很熟悉了，上面的 "Pull Request" 在代码审查这里很好用；
- LGTM：可用于 GitHub 和 Bitbucket 的 PR 代码安全漏洞和代码质量审查辅助工具；
- Phabricator：Facebook 开源的 git/mercurial/svn 代码审查工具；
- PullRequest：GitHub pull requests 代码审查辅助工具；
- Pull Reminders：GitHub 上有 PR 需要你审核，该插件自动通过 Slack 提醒你；
- Reviewable：基于 GitHub pull requests 的代码审查辅助工具；
- Sider：GitHub 自动代码审查辅助工具；
- Upsource：JetBrain 内部部署的 git/mercurial/perforce/svn 代码审查工具。
