关于Codereview的硬性落实

    软件和许多企业政策很相似，规定条文，包括辅助工具都是虚的，关键是“硬性落实”，是否做到“真正落实执行”，是一个项目成败的基本。

以下是我回答的一个JE朋友的codereview的个人经验观点，希望对大家有好处。

楼主也做 codereview， 我们以前也和圣何塞做协同开发， 硅谷的规范很严谨。

后来就硬性书写了代码规范，主要是java, 用checkstyle。
1. 我们把 codereview 这个环节安排在开发单元测试完成后，提交给QA以前做这个工作。

2. 必须硬性严格通过codereview，会让每个开发者打开自己的code，在多媒体会议室接受review， 参与者还有他的leader和相关架构人员，

3. review result会提交给dev，然后dev再修改，再review，直到满意通过。

4. 记住，一定要"硬性执行"codereview， 许多程序员天生的坏习惯，坚持三次review以后，dev就会有责任感，抛弃自己的陋习，完全遵守代码规范了【以后codereview的工作也就越来越快，因为大家都遵守这个规范了】。

5. dev 根据review result 更新自己的代码后，必须完成单元测试，然后在接受codereview, codereview成功通过后，然后dev再申请 reviewer通知QA组开始测试。

6. QA只接受codereviewer的测试申请【也就是说， QA接受不到 codereviewer的测试申请，是不会对相关项目做测试的，这就是硅谷硬性规范】

7. 按照这个程序，有时候你会接近 零 bug。

8. 你甚至可以把codereview 的复查功能添加到每天编译日程中，不满足规范的，就会导致daily build不成功，就找相关的dev，让其硬性完成code的规定。

这个过程刚开始执行的时候，程序员会有抵制态度，但是一定要硬性执行，让高层参与，只要好硬性执行三次以后，以后会产生一个黄金项目。