当,规范什么都不是

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

直到后面成为一个上了年纪开发。我之所以说,规范什么都不是,是因为很多企业规范都有,可是就是没有人来执行。

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

所以,今天的问题是:

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

先了解一下规范有哪些?

image

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

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

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

我是大错特错了。

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

反对编码规范的人很多,下面是一些常见的理由,对于这些理由,我以前是深信不疑。

 

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

规范简单的可以分为两类,第一类规范是可以使用工具强制执行的,另一类规范是暂时无法用工具来强制执行

 

第一类很简单,

比如,我们说的编码规范,在我们上线编译的所有java代码都要通过checkstyle(静态代码格式检查)代码,编译不通过自己改吧。这样做后,无须其他人员参与,简单粗暴好使。

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

image

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

当然,我们也把fingbug加入到检查中,以确保一些代码缺陷能早期发现,并无法通过编译。

 

第二类比较麻烦一些,因为它的确需要到人工干预了。

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

看一个例子

image

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

image

 

这种feedback可以用于做360环评的数据依据。

总结一下,对于无法使用工具强制执行的,需要一个体系来保证有人来干预,并进行留痕,以确保规范能够深入人心,并得到提高。

很多公司难以对具体技术员工进行绩效评估,就是因为无法建立其稳定、有效的评估体系 -- 说的太远。

 

所以,今天的话题就到这里,规范什么都不是,能执行的规范就是法宝!夏娃

posted on 2018-09-04 12:02 一望无际的南 阅读(...) 评论(...) 编辑 收藏

导航

公告