每日一圖，喚醒你迎接美好的一天
膩害吧^^，問題來了：請問這是男手OR 女手？
正文：
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源碼分析和大數據等多個知識點。如果你想拿高薪的，想學習的，想就業前景好的，想跟別人競爭能取得優勢的，想進阿里面試但擔心面試不過的，你都可以來，群號為：636532962
注：加群要求
1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加。
3、如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加。
4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加。
5.阿里Java高級大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知！
6.小號或者小白之類加群一律不給過，謝謝。