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 ?？磥鞧oogle中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開發手冊可以持續改進，吸納百家之長，成為每個入門程序員必看的手冊。
原文鏈接:https://www.toutiao.com/i6459605525188313614/
喜歡對你有幫助的話記得加個關注不迷路哦
還有關注我私信回復【資料】可以領取到一些個人收集的面試及電子書資料，或許對你有幫助！
