當，規範什麼都不是

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

總結一下，對於沒法使用工具強制執行的，須要一個體系來保證有人來干預，並進行留痕，以確保規範可以深刻人心，並獲得提升。

不少公司難以對具體技術員工進行績效評估，就是由於沒法創建其穩定、有效的評估體系 -- 說的太遠。

 

因此，今天的話題就到這裏，規範什麼都不是，能執行的規範就是法寶！