代码Review，Review些什么？如何Review？

从我个人面试经历来看，执行代码Review的公司要比执行了TDD的公司稍微多一点，不过我了解到的大多数Review的方式和内容我感觉问题很大。大多数人和公司一是不知道为何Review，而是Review的方式也不对。造成Review流于形式，实际上也起不到多大作用。甚至有些公司Review的目的是为了寻找Bug。

首先说为何Review。我认为Review代码有如下几个目的。

1. 保障代码的可阅读性。当一个程序员写完一块代码，经过自己测试、重构后，认为已经达到交付标准，需要给其他人Review。这时候其他人首先要确认的是自己能比较容易看懂他的代码逻辑，这样才不会出现代码的孤岛，导致以后这块代码只能他一个人来修改，其他人参与变得困难。可阅读性包括命名（类、方法、变量）、代码格式、方法长度、类的大小、代码层次等很多方面。

2. 其次是从代码设计的原则上看，是否违反一些公认的设计原则。如SOLID原则、迪米特原则、高内聚低耦合原则。这些原则保障了我们的代码逻辑清晰、容易修改。

3. 代码是否编写了合适的单元测试，测试的代码是否可阅读。没有单元测试，代码的质量很难保证，特别是逻辑计算比较复杂的，如果没有单元测试，依靠集成测试和协议测试，很难保证所有情况的覆盖。单元测试代码也要具有可阅读性，和代码要求一样，否则将来测试代码会变得不可维护。
   

4. 再次从性能角度，看代码中是否有影响性能的地方，比如在循环里面查询数据等。看代码能否满足产品的性能需求。

    寻找Bug不应该是代码Review的任务，如果通过Review就能发现Bug，那么Review的人和编写的人水平差距就过大了，编写的人水平可能也太差。Bug要靠单元测试、协议测试、集成测试来保障。

然后再说下如何进行代码Review。我看到不少公司是定期进行，比如每周一次。一群程序员聚集在一起，对这一周编写的代码进行集体Review。我个人认为这不是个好的实践。比如一个8人的团队，一周下来代码可能数千行的改变，有N个Feature，整个Review完需要数个小时。这样疲劳战下来，对人的精神和心智压力很大，很难进行有效率的Review。况且代码太多，超出一个人能很快掌握的程度。我觉得效果不会好。

正确的做法是每完成一小块就进行Review。这个小块是多小呢？我认为要一个Feature 对应多个Review。一个Feature下的某个模块就可以进行一次Review。Review的时机可以在从自己的版本库合并到主库的时候进行，Git版本控制工具给了我们很好的Review时机。代码行数控制在100行左右为佳，尽量控制不要太长代码的Review，更不要多个Feature合起来进行Review。Review的时候，尽可能让Review人和编写人坐一起。首先让编写人讲述自己的问题以及编写思路，然后逐步过自己的代码，有问题当场讨论并修改。

另外一个问题是很多团队Review方式就是某个Leader Review其他人的代码，其他人都是被Review对象。这样不是代码Review，而是工作检查。一是Leader大量时间会消耗在Review上，二是对其他人成长并不利。合适的方式是Team内交叉Review，就像结对编程一样，鼓励随机进行。这样大家可以相互学习，共同提高。

对比较大的团队，还可以进行随机的事后Review。任何人每天可以花上一段时间，去看公司其他人写的代码并编写评论。这样有利于整个公司内技术的相互交流。不过这样由于不容易涉及业务，更多可能是编码风格、编程技巧上进行交流了。