在阿里，搞业务的团队要想推行CR是非常困难的，因为经常是人被业务推着走。然而最近因为团队里有部分写PHP代码的同学要转型到java上面，而这两种语言的思维逻辑完全不同，为了保证代码质量，决定引入CR。
Google一下Code Reivew这个关键词，你就会发现Code Review的好处基本上是不存在争议的，代码有这几种级别：1)可编译，2)可运行，3)可测试，4)可读，5)可维护，6)可重用。通过自动化测试的代码只能达到第3)级，而通过Code Review的代码少会在第4)级甚至更高。所以基本问题就在如何做好CR上面。
1.控制好CR的粒度
在阿里，业务永远是第一位的，这点毋庸置疑。如果一味地为了CR跟业务干仗，可能是个不太聪明的决定。所以作为团队的leader可以在项目不同时期制定不同粒度的检查机制。根据不同时期项目需求的松紧来确定不同粒度的CR流程
2.富有同理心
在review和被review的时候心态要好。如果是代码review者，发现问题后最好跟代码编写人明确问题所在，帮他理清修改思路。被review 者也要虚心接受review 结果，毕竟代码检查也是一项耗心耗力的事情，尊重rev者的付出，根据结果进行辩证性修改。这两个过程，对彼此两个人都有提升。
3.采用适合的CR方案，代码审查的方式方法，在网上一搜一大把，我这里面只挑选我自己发现的很重要的步骤来说说：
1）统一的代码规范，明确规定coding规则，这个步骤可以在平时多普及，在项目工期紧张的时候可以通过自测和自动化检测来保证。《重构》 和 《Clean Code》 对代码比都有非常详细的描述。开展code review 团队的工程师应该熟读这两本书。
2）控制每次CR的代码量。每次 review 包含 200 行左右代码是比较理想的，最多不要超过 400 行。
3）作者应该提供清晰的 commit note。commit note很重要也很影响review 的效率，好的CN应包含改动的目的以及实现方式的概述。
写代码不易，改代码更难。珍惜每一个给我提的意见，因为每个意见可能是对方走过弯路吃过亏的经验教训。珍惜每一次给他人review 代码的机会，可以让我从发现的问题中得到警示。
