为了保证代码质量，我们团队内部一直在推行Code Review。现在Code Review帮我们发现了很多代码的问题，提升了代码的可读性和质量，同时我们在Code Review上也花费了很多时间，有些地方感觉还是有优化空间的，例如：我们更多的是代码评价，较少的当面沟通；Code Review更多的停留在编码规范和代码语句层面，设计思路/设计模式Review较少；Review不够频繁，一次提交的代码太多等等。下面是我整理的做Code Review的一些Tips，大家看对我们是否有借鉴意义，也总结一下我们如何做能够花费较少的时间，取得更大的效果。
Code Review的目的：
- Code Review的最大的功用是纯社会性的。如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。
- Code Review是工程师之间进行技术交流的非常好的方式。它的最终目的并不在与发现fault，而是在于交流和传授。是从junior到senior的最好方式。最好是由junior的工程师写代码，然后由senior的工程师来review。senior的工程师可以在review的过程中把他的一些经验传授给junior的工程师。
- Code Review主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。
Code Review不是什么：
- Code reviews不应该承担发现代码错误的职责。代码中的bug和错误应该由单元测试，功能测试，性能测试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方）
- Code reviews不应该成为保证代码风格和编码标准的手段。编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。代码规范比起程序的逻辑和对需求设计的实现来说，太不值得让大家都来了。
10年前，上面这两件事会是理所当然的（10年前的中国的软件开发还没有Code Review呢），今天，在中国的很多公司上面这两件事依然被认为是Code Review最重要的事，所以，我能够看到很多开发Team抱怨Code Review就是一个形式，费时费力不说，发现的问题还不如测试，而评审者们初了在代码风格上有些见术，别的也就没什么用了，长而久之，大家都会开始厌烦这个事了。 所以，在今天，请不要把上面的那两件事分散了Code Review的注意力，取而代之的是，对于Bug，程序的作者要在Review前提交自己的单元测试报告（如：XUnit的测试结果），对于代码规范，这是程序作者自己需要保证的，而且，有一些工具是可以帮你来检查代码规范的。 当然，上述这些言论并不是说，你不能在Code Review中报告一个程序的bug或是一个代码规范的问题。我只是说，那并不是Code Review的意图。
如何做Code Review：
- 经常进行Code Review。千万不要等整个大厦都盖好了再去Review，而是当有了地基，有了框架，有了房顶，有了门窗，有了装修，的各个时候循序渐进地进行Review，这样反而会更有效率，也更有帮助。以前经历过几个相当痛苦的Code Review，那几次Code Review都是在程序完成的时候进行的，当你面对那近万行的代码，以及掺和在一起的功能，你会发现，整个Code Review变得非常地艰难，用不了一会儿，你就会发现大家都在拼命地打着哈欠，但还是要坚持，有时候，这样的Review会持续3个小时以上，相当的夸张。而且，会议上会出现相当多的问题和争论，因为，这就好像，人家都把整个房子盖好了，大家Review时这挑一点那挑一点，有时候触动地基或是承重墙体，需要大动手术，让人返工，这当然会让盖房的人一下就跳起来极力地维护自己的代码，最后还伤了团队成员的感情。
- 先Review设计实现思路，然后Review设计模式，接着Review成形的骨干代码，最后Review完成的代码，如果程序复杂的话，需要拆成几个单元或模块分别Review。当然，最佳的practice是，每次Review的代码应该在1000行以内，时间不能超过一部电影的时间——1.5小时（因为据说那个一个正常人的膀胱可以容纳尿液的最长限度）
- Code Review不要太正式，而且要短。忘了那个代码评审的Checklist吧，走到你的同事座位跟前，像请师父一样请他坐到你的电脑面前，然后，花5分钟给他讲讲你的代码，给他另外一个5分钟让他给你的代码提提意见，这比什么都好。而如果你用了一个Checklist，让这个事情表现得很正式的话，下面两件事中必有一件事会发生：1.只有在Checklist上存在的东西会被Review。2.Code Reviews变成了一种礼节性的东西，你的同事会装做很关心你的代码，但其实他心里想着尽快地离开你。只有不正式的Code Review才会让你和评审者放轻松，人只有放松了，才会表现得很真实，很真诚。记住Review只不过是一种形式，而只有通过相互的讨论得到了有意义和有建设性的建议和意见，那才是最实在的。不然，作者和评审者的关系就会变成小偷和警察的关系。
- 尽可能的让不同的人Review你的代码。如果可能的话，不要总是只找一个人来Review你的代码，不同的人有不同的思考方式，有不同的见解，所以，不同的人可以全面的从各个方面评论你的代码，有的从实现的角度，有的从需求的角度，有的从用户使用的角度，有的从算法的角度，有的从性能效率的角度，有的从易读的角度，有的从扩展性的角度……，啊，好多啊，还让不让人活了。不管怎么说，多找一些不同的人会对你很有好处。当然，不要太多了，人多嘴杂反而适得其反，基本上来说，不要超过3个人，这是因为，这是一个可以围在一起讨论的最大人员尺寸。下面是几个优点：1.从不同的方向评审代码总是好的。2.会有更多的人帮你在日后维护你的代码。3.这也是一个增加团队凝聚力的方法。
- 学会享受Code Review。如果你到了一个人人都喜欢Code Review的团队，那么，你会进入到一个生机勃勃的地方，在那里，每个人都能写出质量非常好的代码，在那里，你不需要经理的管理，团队会自适应一切变化，他们相互学习，相互帮助，不仅仅是写出好的代码，而且团队和其中的每个人都会自动进化，最关键的是，这个是一个团队。
