Code Review 的首要目的是改善和保证代码质量，预防 bug。此外还有益于制定团队代码规范，形成团队技术氛围，加深技术团队成员沟通，老带新互助成长等等。
有些团队里 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 代码审查工具。
CodeReview 我会重点关注如下事情：
- 确认代码功能：代码实现的功能满足产品需求，逻辑的严谨和合理性是最基本 的要求。同时需要考虑适当的扩展性，在代码的可扩展性和过度设计做出权 衡，不编写无用逻辑和一些与代码功能无关的附加代码。 在真正需要某些功能的时候才去实现它，而不是你预见到它将会有用。 —— RonJeffries
2. 编码规范：以集团开发规约、静态代码规约为前提，是否遵守了编码规范，遵 循了最佳实践。除了形式上的要求外，更重要的是命名规范。目标是提高代 码的可读性，降低代码可维护性成本。
3. 潜在的 BUG：可能在最坏情况下出现问题的代码，包括常见的线程安全、业 务逻辑准确性、系统边界范围、参数校验，以及存在安全漏洞 ( 业务鉴权、灰 116 > 阿里工程师的自我修养 产可利用漏洞 ) 的代码。
4. 文档和注释：过少（缺少必要信息）、过多（没有信息量）、过时的文档或注释， 总之文档和注释要与时俱进，与最新代码保持同步。其实很多时候个人觉得 良好的变量、函数命名是最好的注释，好的代码胜过注释。
5. 重复代码：当一个项目在不断开发迭代、功能累加的过程中，重复代码的出现 几乎是不可避免的，通常可以通过 PMD 工具进行检测。类型体系之外的重复 代码处理通常可以封装到对应的 Util 类或者 Helper 类中，类体系之内的重复 代码通常可以通过继承、模板模式等方法来解决。
6. 复杂度：代码结构太复杂（如圈复杂度高），难以理解、测试和维护。
7. 监控与报警：基于产品的需求逻辑，需要有些指标来证明业务是正常 work 的，如果发生异常需要有监控、报警指标通知研发人员处理，review 业务需 求对应的监控与报警指标也是 Code Review 的重点事项。
8. 测试覆盖率：编写单元测试，特别是针对复杂代码的测试覆盖是否足够。
若有收获，就点个赞吧
0 人点赞
