Code Review之代码规范篇

由于先前公司做了一个外国的项目,那个项目好像基于掌上电脑的一个小网站(具体的不敢问头太多),结果我们的HTML代码写的不好,
被国外的人说我们的代码结构不好,CSS里属性值老多重复等.在我看来可能当时这样一种网站由于时间进度\项目规模等各种原因,没有足够的人手去把那些东西写好.

  结果后来这个单子就丢了.
  头就急了,后来就让我负责全部开发团队的代码规范的Code Review事宜.他在向其他人宣布我的这一职责也明确说了.Code Reveiw中我主要检查代码规范,至于具体其他性能上,设计上的就不是我的范畴了

  但问题是:代码规范都是静态的东西.怎么执行?执行到什么程度好呢?你比如说:几乎所有的语言的代码缩进都要求4个空格,如果让团队每个人都做到这一点?把它们的各种开发工具编辑器的都设置一遍吗?让他们自己设置?如果他们重新安装的电脑了怎么办?
  看似代码缩进4个空格的这个简单问题,执行起来确有各种可能,这里绝对不能有教条思维,

  还比如javascript,变量没有申明前,就不要直接使用.但是你如果真的用了,也没有关系,程序也能跑.这一点怎么执行呢?我还要辛辛苦苦用jslint.com的工具来检查.
程序员出现这种问题,只是道德问题,而不是法律问题;而头非要反过来说是警察和小偷的问题,是法律问题.

争论归争论,做还得做；

  我初步的步骤如下；
  　1)调度svn命令,每天增量下载所有要Reivew项目代码的Source Code．
    2)Javascript:　　jslint.com
      HTML:   http://validator.w3.org/    
      CSS:    http://jigsaw.w3.org/css-validator/
      JSP:    PMD
      Java:   PMD/Checkstyle
      C#:     unknown
      aspx:   unknown
    
用这些工具检查下载下来的各种类型文件，然后形成一个Jira Issues,提交到SVN版本库里的相应的作者．

这个过程是蛮麻烦和蛮琐碎的．

　　1)整合这些工具,形成jira issue比较麻烦.
　　2) jira issues还要跟踪，重新下载被Review的svn代码,检查,然后要向发生问题的解释,然后让他执行,这个比较费时,工作量无法估量

最麻烦的是头还要我形成一个报告,列出哪些是团队经常犯的代码规范问题 ?哪些人经常犯?我说这些问题你直接去看jira,他说他不看那些detail的报告，他要那些总结性的．
我的哥，这些报告如果没有每一个平台去自动形成，那么就意味着我要自己手工去归纳，我归纳出来的这样的报告有意义吗？这样的报告只是静态的．这样的工作持续会持续多长时间？
　 我倒是想写一个软件平台，把上面的代码检查工具整合一下，自动形成jira issue，然后自动得出报告，但是这要费大量时间，而我又有其他工作．

各位，你们是如果做代码规范的Code Review的?

lz可以看看《如何高效的做代码检视》这篇博客，如何有效的做代码的在线检视，提高效率，而且跟踪、统计、分析等面面俱到，应该可以解决目前你的问题。

可以看看sonar
http://www.sonarsource.org/

恩，硬性的代码规范可以snoar checkstyle这样的工具帮忙吧

用持续集成工具，hudson, teamcity等

那你就彻底是人肉CheckStyle+FindBug+PMD...了

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

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

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

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

代码规范对于项目后期维护时非常重要的，我们的项目现在就碰到规范的问题。

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