当，规范什么都不是

最开始接触规范的时候是在世界500强企业里面，我记得架构师当时给出了编码规范，namespace命名规范，数据库对象命名规范。最开始的时候，我也是比较轻视这块的东西。

直到后面成为一个上了年纪开发。我之因此说，规范什么都不是，是由于不少企业规范都有，但是就是没有人来执行。

摆在纸面上的规范什么都不是！

因此，今天的问题是：

如何让纸面上的规范落实在平常的开发运维过程当中？

先了解一下规范有哪些？

来了解一下google怎么看待规范的。。http://www.vaikan.com/google-coding-standards/

咱们在谷歌所作事情中另一个让我感到异常有效、有用的制度是严格的编码规范。

在到Google工做以前，我一直认为编码规范没有什么用处。我坚信这些规范都是官僚制度下产生的浪费你们的编程时间、影响人们开发效率的东西。

我是大错特错了。

在谷歌，我能够查看任何的代码，进入全部谷歌的代码库，我有权查看它们。事实上，这种权限是不多人能拥有的。可是，让我感到惊讶的倒是，如此多的编码规范—缩进，命名，文件结构，注释风格—这一切让我出乎意料的轻松的阅读任意一段代码，并轻易的看懂它们。这让我震惊—由于我觉得这些规范是微不足道的东西。它们不可能有这么大的做用—但它们却起到了这么大的做用。当你发现只经过看程序的基本语法结构就能读懂一段代码，这种时间上的节省不能不让人震撼！

反对编码规范的人不少，下面是一些常见的理由，对于这些理由，我之前是深信不疑。

 

规范的执行到底怎么解决呢？

规范简单的能够分为两类，第一类规范是能够使用工具强制执行的，另外一类规范是暂时没法用工具来强制执行。

 

第一类很简单，

好比，咱们说的编码规范，在咱们上线编译的全部java代码都要经过checkstyle（静态代码格式检查）代码，编译不经过本身改吧。这样作后，无须其余人员参与，简单粗暴好使。

使用统一的Maven编译模型下面，配置

checkstyle:check -Dcheckstyle.config.location="http://jenkins.umoffice.com/UMCheckStyle.xml"

固然，咱们也把fingbug加入到检查中，以确保一些代码缺陷能早期发现，并没有法经过编译。

 

第二类比较麻烦一些，由于它的确须要到人工干预了。

咱们的实践中是采用jira中的upRaise工具，进行Give Feedback方式

看一个例子

例子二，基于jira case来进行feedback

 

这种feedback能够用于作360环评的数据依据。

总结一下，对于没法使用工具强制执行的，须要一个体系来保证有人来干预，并进行留痕，以确保规范可以深刻人心，并获得提升。

不少公司难以对具体技术员工进行绩效评估，就是由于没法创建其稳定、有效的评估体系 -- 说的太远。

 

因此，今天的话题就到这里，规范什么都不是，能执行的规范就是法宝！