团队代码规范实践之路

又到了一年一度新人入职的时候了，很多团队再次开始为规范新人的代码水平犯愁。代码规范的好处相信大家都知道，就不再重复了，大家都知道。那么如何高效地达到这一目标，不让部门制定的代码规范沦为一纸空文呢？今天我向大家介绍杭研质量保障部近期的编码规范检查经验，希望能有所帮助。

我们的代码规范检查实践是基于Checkstyle工具。Checkstyle是一款针对Java的轻量级代码检查工具，历经多年发展已经达到了很成熟的阶段，跟多种开发工具能很好地集成在一起，支持强大的自定义检查规则，对于杭研后台制订的 Java编码规范，仅有两三点不支持。

Checkstyle的详细介绍参考官网：http://checkstyle.sourceforge.net/，感兴趣的童鞋可以深入了解一下。

一、检查流程

1、团队内就 Checkstyle检查规则达成一致，制订Checkstyle规则文件。

2、开发人员本地使用规则文件在Eclipse中进行自查，争取把错误消灭在代码提交之前。

3、Jenkins中使用Checkstyle插件定时检查SVN代码库并把检查结果推送给团队成员。

4、在前期，检查结果出来后需要有专人跟进修改，直到团队养成习惯。 

图 1 检查流程示意图

至于Checkstyle在 Eclipse/Jenkins插件的安装、配置和使用详情，可以参考我的这篇博文：博文链接，此处不再赘述。

二、实践成果

我们在测试开发组内的Dagger、Emmagee开源项目以及一些自动化测试代码项目中进行了试用，运行一个多月以来，效果显著。

首先，团队的编码规范程度得到了提升，代码规范检查能够完全按照团队所制定规则执行。

比如在Orange项目中，使用了上述检查模型后，代码检查的错误率直线下降，很快就从200+变成了如今的零错误。Jenkins中检查趋势图如图2所示： 

                                图2: Orange代码检查趋势图
其次也是显而易见的，检查效率也大幅提升，用Jenkins自动检查替代了痛苦的人肉review。

除了上述的收获，我们也有一些心得体会：

1、常见代码规范错误

表 1 常见代码规范错误列表

2、修改代码的工作量情况

我们也对被检查的项目统计了修改代码的工作量，一些项目的错误数看着非常的多，其实修改起来还是比较快的，一些空格相关的错误通过Eclipse格式化就可以自动修改完成，变量命名错误的问题也可以通过在Eclipse中一次修改完变量的所有引用解决。

表 2 各项目代码修改工作量

3、不同类型项目的规范差异

含有测试代码的项目中常会使用TestNg等工具，存在@Test(groups ={ "pass", "online" })等语法，这时候})两个符号之间默认是紧跟的，这里}后面需要空格的规则就有些不适用，会导致检查出来很多错误。另外一些开发项目中可能会存在直接引入的开源代码包，包名不是com.netease开头，这种情况下，如果默认检查包名com.netease开头的话会出现很多错误。所以规范在制定初稿后可以试用一段时间再确定最终版本，也可以去除一些确实不适合团队的规范。

4、发现的开发人员代码问题

我们在检查一些接口测试项目时也发现了开发人员在一些接口方法、参数命名等问题上也存在没有按照编码规范的问题。 

三、后续展望

1、杭研质量保障部制定统一编码规范， 部门内所有代码提交都能自动经过代码规范检查。

2、QA熟悉编码规范检查相关工作流程后，尝试扩大该编码规范工作的影响范围至产品项目组。

3、Java之外的编程语言，比如C/C++，Ruby等，也可以考虑采用类似的高效方式检查编码规范。

网易云新用户大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者孔庆云授权发布。