最开始接触规范的时候是在世界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环评的数据依据。
总结一下，对于无法使用工具强制执行的，需要一个体系来保证有人来干预，并进行留痕，以确保规范能够深入人心，并得到提高。
很多公司难以对具体技术员工进行绩效评估，就是因为无法建立其稳定、有效的评估体系 -- 说的太远。
所以，今天的话题就到这里，规范什么都不是，能执行的规范就是法宝！