Code Review之代码规范篇

以前在华为做外包的时候他们就是这么干的，checkstyle findbug pmd code review插件，以及代码缩进，字符编码全定制到eclipse中，给开发人员一个eclipse完事。他们用CI每天晚上静态检查，跑用例,编译后发邮件给DEV，第2天早上直接看报告，里面报告细致到可以算出每一个人一天的代码行数，真的就按生产工人一样了。。 。 另外加上JIRA工作流或者IBM的CQ CC等工具，一套全了。。。

这个过程对没经验的开发人员开始很受不了，特别是测试用例，不过做完一个项目后都习惯了，以后写代码都会养成好习惯，而且出去面试可以忽悠一批公司。。。。。。

看来华为早就想到这些呢. CI作静态检查,并且结合Jira,真的和我想的一样,可惜我不在华为外包公司,但是我面临着这种界定模糊的任务.

楼主也做 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的规定。

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