正文：

2016年底，阿里巴巴公開了其在內部使用的Java程式設計規範。隨後進行了幾次版本修訂，筆者當時看到的版本為v1.0.2版。下載地址可以在其官方社群——雲棲社群找到。

筆者作為一名有數年工作經驗的Java程式設計師，仔細研讀了這份手冊，覺得是一份不可多得的好材料。正如阿里巴巴在釋出時所說，“阿里巴巴集團推出的《阿里巴巴Java開發手冊（正式版）》是公司近萬名開發同學集體智慧的結晶，以開發視角為中心，詳細列舉了如何開發更加高效、更加容錯、更加有協作性，力求知其然，更知其不然。結合正反例，讓Java開發者能夠提升協作效率、提高程式碼質量。”同時，阿里巴巴也期望這套Java統一規範標準將有助於提高行業編碼規範化水平，幫助行業人員提高開發質量和效率、大大降低程式碼維護成本。

其實早在多年前，Google就已經把公司內部採用的所有語言的編碼規範(其稱為 Style Guide )都開源在Github上。這份清單中包括了 C++ 、 Objective-C 、 Java 、 Python 、 R 、 Shell 、 HTML/CSS 、 JavaScript 、 AngularJS 、 Common Lisp 、 Vimscript等語言的程式設計規範。並且Google還發布了一個用於檢查樣式合規性的工具 cpplint以及在Emacs中使用Google程式設計樣式的配置檔案 google-c-style.el 。看來Google中Emacs粉比Vim粉要強勢的多。

Google為什麼要釋出這樣的Style Guide呢？因為它認為幾乎所有的開源專案都需要有一組約定來規範如何編寫程式碼。如果專案中的程式碼都能保持一致的風格，那麼即使程式碼再多也會很容易的被人理解。

Google的這份程式設計規範包含了很多方面，從”對變數使用camelCase命名法”到”絕不要使用全域性變數”到”絕不允許例外“等。其Java程式設計規範包含7大部分，分別為介紹、原始檔基本要求、原始檔結構、格式化、命名、程式設計實踐和Javadoc。每一部分又細分為很多子條目。如果採取條規範的原因不是很容易理解，都會配有相應的示例或者引用文章。

由於Google的這份程式設計規範目前只有英文版本，所以在中國的程式設計師中只有少部分人知道它的存在。並且只有更少的團隊在真正的應用它，其中就包括我的團隊。我們團隊根據Google的 Java style guide也演化出了自己的團隊版本，放置在團隊共享wiki上供大家隨時查閱。我們根據自身的專案特點豐富了”程式設計實踐”裡的內容，並且新加入一個章節來描述編寫Java程式碼的一些原則，比如簡潔程式碼、組合優於繼承、stream優於for迴圈等。

我想阿里巴巴釋出的Java開發手冊之所以叫做”開發手冊”，而不是像Google那樣叫做“Style Guide(樣式風格)”，是因為它不僅僅侷限於style guide這一方面，而是以Java開發者為中心視角，劃分為程式設計規約、異常日誌規約、MYSQL規約、工程規約、安全規約五大塊，再根據內容特徵，細分成若干二級子目錄。根據約束力強弱和故障敏感性，規約依次分為強制、推薦、參考三大類。

該開發手冊中的每一條都值得了解。限於篇幅原因，這裡只列出”程式設計規約“中有感受的幾條來評述一下。

命名規約的第15條描述了在Service/DAO層對於資源的操作的命名規範。這一條的參考價值極大，因為我所有待過的團隊對於這一點都沒有明顯的約束，每個團隊都有五花八門的實現。如果能遵守這一點，那麼我們在操作資源時就會減少一些困擾。

這是常量定義的第2條。從這一點可以看出阿里巴巴對程式碼可讀性的細節扣的很嚴格。我也很贊同這一點。程式碼只需編寫一次，而會被檢視無數次，所以要力爭在第一次編寫的時候儘可能少的引入歧義。

格式規約的第1條終於終結了括號之爭。這一條需要強制遵守，那麼左大括號換行一派則被徹底排除在阿里巴巴之外。有人說不推薦左大括號換行，可以減少行數，增加單個螢幕可以顯示的程式碼行數。而有的人反駁說現在螢幕已經足夠大，不換行則破壞了對稱之美。其實對於我來說兩種格式都有各自的好處，我都可以接受，只要團隊能夠堅持使用其中之一即可。

使用空格代替tab字元進行縮排已經成為了程式設計界的共識。其主要原因是不同的平臺甚至不同的編輯器下tab字元的長短是不一樣的。不過Google在其《java style guide》中規定縮排為2個空格，而阿里巴巴約定為4個空格。由於4個空格的縮排比2個空格的縮排長一倍，所以如果在程式碼巢狀過深的情況下可能會很快超過單行最多字元數(阿里巴巴規定為120個)的限制。不過這個問題可以從另一個方面進行思考，如果由於縮排的原因導致單行字元數超標，這很可能是程式碼設計上有壞味道而導致巢狀過深。所以最好從調整程式碼結構的方面下手。

關於換行，Google並沒有給出明確的要求，而阿里巴巴則給出了強制性的要求。Google特別提示可以通過一些重構手法來減少單行字元長度從而避免換行，這一點我頗為認同。關於引數，很多方法呼叫超過120個字元需要換行，這暴露除了過長引數列的程式碼壞味道，解決方式之一就是使用重構手法的Replace Parameter With Method的方式把一次方法呼叫化為多次方法呼叫，或者使用Introduce Parameter Object手法創造出引數物件並進行傳遞。

這是《Effective Java》以及其他文章中經常提及的優化方式，而且面試初級Java工程師時幾乎是一個必考點。其實不僅是在迴圈體內，所有需要進行多次字串拼接的地方都應該使用StringBuilder物件。

這其實就是經典的原則‘Principle of least privilege’的體現。我們必須遵循這一原則，但不知為何阿里巴巴將其級別列為“推薦”。

編寫程式碼時，對引數進行校驗是不可避免的。詳細說又扯到“防禦式程式設計”和“契約式程式設計”的話題上。這兩項之所以列為參考，並沒有強迫大家遵守。

看到這一條我已經笑出來了。這一條說的很好，註釋是用來闡述問題的，如果看了註釋還一頭霧水，那麼這樣的註釋不要也罷。使用中文沒什麼可丟人的，解決問題才是王道。

阿里巴巴對該條的說明非常到位。其實我們團隊在編寫程式碼時預設是沒有任何註釋的，因為我們追求的是self-explanatory methods。即程式碼本身已經就能說明它的用途。只有在很少的情況下需要添加註釋。

程式設計規約的第九部分都是很好的tips，值得去了解和學習。

除了程式設計規約之外，日誌規約、MySQL規約、工程規約和安全規約也都有極高的參考價值，這也是比Google的Java Style Guide出色的地方。這裡就不再評述了。

阿里巴巴公佈這個Java開發手冊絕對是值得讚賞的事情。最後我也想給其提幾點建議：

建議使用公開wiki的方式釋出該手冊，而不是採用pdf的方式。因為如果像google那樣是公開wiki方式的話，可以方便大家參與修正和改進，並且可以看到版本歷史。

該手冊並沒有明確的版權許可，只是在頁尾處加入了“禁止用於商業用途，違者必究”的字樣。Google的style guide的版權為CC-By 3.0 License，建議阿里巴巴能夠指明其版權。

手冊中的部分示例程式碼並沒有遵守其列出的程式設計規約，有點打臉之嫌。比如以下示例程式碼：

Iterator<String> it = a.iterator;

while(it.hasNext){

String temp = it.next;

if(刪除元素的條件){

it.remove;

}

}

其while和if關鍵字與小括號之間並沒有空格，違反了該手冊中3. 【強制】if/for/while/switch/do等保留字與左右括號之間都必須加空格。這一規則。

集合處理中可以多推薦一些Java8的集合操作方法。

有些名詞沒有過多解釋，比如很多人可能都不知道什麼叫一方庫、二方庫。

希望除了這份開發手冊以外，阿里巴巴也可以推出對應的checkstyle配置檔案以及Intellij、Eclipse的配置檔案。畢竟格式化這些事都可以交由IDE來解決，通過在構建時使用checkstyle外掛也可以防止不合規的程式碼遷入到倉庫，從源頭上保證程式碼樣式的一致性。

最後，希望這份Java開發手冊可以持續改進，吸納百家之長，成為每個入門程式設計師必看的手冊。

好了同學們，我能介紹的也都全部介紹完給你們了，以上的部分就是我想說的內容，如果你也想在IT行業拿高薪，可以參加我們的訓練營課程，選擇最適合自己的課程學習，技術大牛親授，7個月後，進入名企拿高薪。我們的課程內容有：Java工程化、高效能及分散式、高效能、深入淺出。高架構。效能調優、Spring，MyBatis，Netty原始碼分析和大資料等多個知識點。如果你想拿高薪的，想學習的，想就業前景好的，想跟別人競爭能取得優勢的，想進阿里面試但擔心面試不過的，你都可以來，群號為：579581654
本群提供免費的學習指導 架構資料 以及免費的解答
不懂得問題都可以在本群提出來 之後還會有職業生涯規劃以及面試指導
進群修改群備註：開發年限-地區-經驗
方便架構師解答問題