代码 review 介绍

一、为什么要review

1、提高代码质量

这是代码 Review 的初衷，也是代码 Review 最直接的价值。Reviewers 根据各自的经验，思考方式，看问题的角度给代码提出各种可能的改进意见，从而形成更好的代码以及产品质量。

我们知道产品问题越晚提出解决它的代价就越大，参与进去的人、要走的流程都会越来越多。代码 Review 可以说是早期解决问题最有效的途径之一了，在代码 Review 中解决掉哪怕一个小问题都能避免后续一堆的麻烦事。

2、形成团队统一的高质量标准

有效的代码 Review 最终会在团队范围内建立起统一的质量标准，并且会随着团队成员的互相学习和促进形成更高的标准。参与者会在代码 Review 的过程中基于具体问题从不同角度提出改进意见，并最终做出当前最佳的选择并形成共识。随着代码 Review 的有效进行，团队成员会有意识地关注代码质量，从而形成越来越高的事实上的质量标准。

3、个人快速成长

通过有效的代码 Review，Author 和 Reviewer 都将获得成长，在 Review 过程中参与人就具体的问题展开深入的讨论，无论是怎么写出整洁的代码、怎么更好地更全面地思考问题、怎么最佳地解决问题，参与人都可以互相取长补短，互相提高。通过具体代码实现进行的讨论往往是最深入和有效的，代码 Review 是开发者提高代码能力最重要的途径之一。

有的人认为代码 Review 就是 Reviewer 帮助查找代码中的 Bug，其实代码 Review 不应该是一个单向的过程，而应该是个双向交流的过程，Reviewer 帮助 Author 提出代码改进意见的同时，也是向优秀的 Author 学习的过程。我们都知道提高代码能力一个有效的途径是阅读优秀的项目代码，但是阅读项目代码有着不小的难度，这也是大部分人没有去执行的原因，而 Review 资深同事的代码，我们在阅读代码的同时能够直接进行有效的沟通，这是一个快速有效的学习途径，尤其对开发经验还不算丰富的开发者而言。

二、什么时候发起 Review

2.1、场景

1. 多人合作；
2. 重要设计

2.2、时机

1. Self-Review ： 提交代码之前，自己审查一遍自己的代码
2. MR (Merge Request) ： 个人分支合并到公共分支（开发主分支）的时候；

三、Review 些什么

1. 变量、方法的命名（是否反映了它们的目的）
2. 实现的逻辑是否已有现成的库可以替代
3. 是否有注释（不好理解的地方需要有恰当的注释）
4. 代码可读性（代码组织层次是否清晰、一致）
5. 代码健壮性（参数是否校验、异常处理、代码改动会不会影响其他功能）
6. 代码可扩展性
7. 代码编写思路是否合理

四、如何快速完成codereview

1.不要刻意地去寻找代码bug

有些代码的逻辑是比较复杂的，如果是很容易就发现的缺陷，大多数情况下评审者自己在编码过程就会发现，那么剩下不容易发现的缺陷要发现也会花费较多的时间，这些问题可以交给测试人员去发现；
如果参与者刻意去找bug会造成顾此失彼，忽略更重要的东西；当然，有些bug你可能一眼就看出来了，那提出来就再好不过了。

2.不要带着抨击和质疑别人能力的心态去进行代码评审

有时候参与者可能心情不好，或者感觉对方是新人就忍不住会抨击对方的代码，这样会比较容易在模棱两可的问题上浪费时间；
参与者可能认为A方法好，评审者可能认为B方法也不坏，这样就会造成没有必要的争论而浪费时间。

3.不要在不确定的问题上争来争去

大家在讨论的时候如果某些问题讨论一段时间以后仍然没有结论，或者需要第三方确认或者评审者不能马上理解参与者提出的意见时，不要花太多时间讨论这些问题；
把这些问题先记录下来，等会议结束后评审者可以与参与者进行线下讨论，同时将这些问题根据自己的理解进行解决，之后给大家一个反馈即可，这样可以节省很多时间。

4.不要听不进别人的意见

有些评审者比较固执，不愿意接受大家的意见，会造成一些不必要的争端和讨论，浪费时间；
当然，有时候参与者的意见不见得是最好的，作为评审者将其作为一个参照的方向和视角，如果存在争论，这些建议也可以做成会议记录，评审者私下和建议提出者讨论以后给大家一个结论。

5.参与者最好不要自己都没想明白就提意见

如果参与者自己没有想明白的事情就去提意见，那么评审者反问的时候会浪费大家的时间；
参与者可以先将自己的想法大致记下来，自己想清楚了之后再提给评审者也是节省时间的办法。

6.评审前最好先通过代码静态检查工具检测

一般规范性的问题都可以通过静态检测工具发现，借助工具是最省事，也是效率最高的，还可以避免大家都评审时提出很多规范性问题，而遗漏了业务逻辑、设计合理性等问题。