关于代码评审（CR）

代码评审本质是一个沟通反馈的过程。

1. 为什么要做代码评审？

• 个体角度：没有人能够保证自己写出来的代码是没有问题的，而规避个体问题的主要方式就是使用集体智慧，也就是团队的力量。
• 团队视角：代码评审的过程，也是一个知识分享的过程，保证一些细节的知识不再是隐藏在某一个人的头脑中，而是放置到了团队的层面。

不过，无论是从哪个角度看代码评审，它的本质，就是沟通反馈的过程。所以沟通要尽可能透明，尽可能及时。把这样的理解放到代码评审中，就是要尽可能多暴露问题，尽可能多做代码评审。

2. 代码评审的角度

做代码评审时，我们可以从下面几个角度来看代码：

(1) 实现方案的正确性

理论上说，实现方案应该是设计评审中关注的内容，但在实际工作中，并不是所有团队都能够很好地执行设计评审，而且设计评审有时也关注不到特别细的点，所以，一些实现方案的问题只有在代码评审中才能发现。

很多程序员，尤其是经验比较少的程序员写程序经常会出现的问题：正常情况一切顺利，异常情况却考虑不足。

(2) 算法的正确性

(3) 代码的坏味道

无论是实现方案的正确性，还是算法的正确性，对于大多数团队来说，都会关注到。但代码坏味道却是很多团队容易忽略的，这里面的关键点就是很多团队对于坏味道的标准太低了。

3. 代码评审的频率

提升评审的频率，比如，每天评审一次。评审周期过长是有问题的，周期过长，累积的问题就会增多，造成的结果就是太多问题让人产生无力感。如果遇到实现方案存在问题，要改动的代码就太多了，甚至会影响到项目的发布。

而提升评审的频率，评审的周期就会缩短，每个周期内写出来的代码就是有限的，人是有心力去修改的。强调短小的价值，只有及时的沟通反馈，才有可能实现这一原则。

如果把代码评审推至极致，就是有个人随时随地来做代码评审。就是把好的实现推向极致，而代码评审的极致实践就是结对编程。

4.记住一句话：

代码评审暴露的问题越多越好，频率越高越好。