最開始接觸規範的時候是在世界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環評的數據依據。

總結一下，對於無法使用工具強制執行的，需要一個體系來保證有人來幹預，並進行留痕，以確保規範能夠深入人心，並得到提高。

很多公司難以對具體技術員工進行績效評估，就是因為無法建立其穩定、有效的評估體系 -- 說的太遠。

所以，今天的話題就到這裏，規範什麽都不是，能執行的規範就是法寶！

當，規範什麽都不是