《阿裡巴巴Java開發手冊v1.4.0（詳盡版）》更新，新增16條設計規約

        <b>-------------- </b><b>2018.6.6日更新 --------------</b>

阿裡巴巴java開發手冊v1.4.0（詳盡版）釋出，新增16條設計規約。設計規約是根據阿裡巴巴實際項目架構經驗提煉而成，主要從uml圖和架構設計原則來規定比較基礎的軟體設計理念，并且明确了超過什麼樣的門檻值需要以什麼樣的方式來呈現設計思維。

代碼的可讀性是指代碼讓人容易閱讀、了解、調試、可預料的程度。提高代碼的可讀性可以為代碼閱讀者節約時間和精力，提升團隊協作效率。熟悉和遵守《阿裡巴巴java開發手冊》的程式設計風格，那隻是“标”，而代碼可讀性的“本”可以追溯到軟體設計階段。根據阿裡巴巴内部的回報聲音來看，對于資料底層結構、狀态圖、以及靈活開發相關的三條，共鳴感最強，那麼詳細點評一下。

<b>1. 資料底層結構</b>

底層資料結構屬于大廈的地基工程，如果地基不穩，那麼上層去修正難度是相當大的，甚至是無法修正。是以設計規約提倡，存儲方案和底層資料結構的設計獲得評審一緻通過，并沉澱成為文檔。有缺陷的底層資料結構容易導緻系統風險高，可擴充性差，重構成本因曆史資料遷移、系統平滑過渡也會陡然增加，是以，存儲方案和資料結構需要認真地進行設計和評審，生産環境送出執行後，需要進行double check。評審内容包括存儲媒體選型、表結構設計能否滿足技術方案、存取性能和存儲空間能否滿足業務發展、表或字段之間的辯證關系、字段名稱、字段類型、索引等；資料結構變更（如在原有表中新增字段）也需要進行評審通過後上線。

<b>2. 狀态圖</b>

業務對象狀态相關的編碼錯誤是引起線上故障的一個重要導火索。多一個狀态，少一個狀态，如果沒有曆史設計文檔沉澱，那麼都是災難性的。如果某個業務對象的狀态超過3個，使用狀态圖來表達并且明确狀态變化的各個觸發條件。狀态圖的核心是對象狀态，首先明确對象有多少種狀态，然後明确兩兩狀态之間是否存在直接轉換關系，再明确觸發狀态轉換的條件是什麼。淘寶訂單狀态有已下單、待付款、已付款、待發貨、已發貨、已收貨等。比如已下單與已收貨這兩種狀态之間是不可能有直接轉換關系的。

<b>3. 靈活開發</b>

靈活開發是當下流行的一種開發模式，相比傳統軟體生産流程，更加快速地傳遞。但是，靈活開發适合于信任度好、了解力強、技術水準相對一緻的創業型團隊。但是在很多公司靈活成為一個抓進度的拔苗助長式的借口。是以避免如下誤解：靈活開發 = 講故事 + 編碼 + 釋出。靈活開發是快速傳遞疊代可用的系統，省略多餘的設計方案，摒棄傳統的審批流程，但核心關鍵點上的必要設計和文檔沉澱是需要的。

<b>--------------</b><b>--------------</b><b>--------------</b>

<b>關于《阿裡巴巴java開發手冊》</b>

《阿裡巴巴java開發手冊》是阿裡内部java工程師所遵循的開發規範，涵蓋程式設計規約、異常日志、單元測試、安全規約、mysql資料庫、工程規約、設計規約等，這是近萬名阿裡java技術精英的經驗總結，并經曆了多次大規模一線實戰檢驗及完善。這是阿裡回饋給java社群的一份禮物，希望能夠幫助企業開發團隊在java開發上更高效、容錯、有協作性，提高代碼品質，降低項目維護成本。

你是否曾因java代碼規範版本紛雜而無所适從？

你是否想過代碼規範能将系統故障率降低20%？

你是否曾因團隊代碼風格迥異而協同困難？

你是否正在review一些原本可以避免的故障？

你是否無法确定自己的代碼足夠健壯？ 

<b>碼出高效，碼出品質！</b>

相比c++代碼規範業界已經達成共識，java代碼規範業界比較混亂，我們期待這次釋出的java代碼規範能夠給業界帶來一個标準，促使整體行業代碼規範水準得到提高，最終能夠幫助企業和開發者提升代碼品質和降低代碼故障率。

<b>阿裡出品，品質保證！</b>

阿裡java技術團隊一手打造出dubbo、jstorm、fastjson等諸多流行開源架構，部分已成為apache基金會孵化項目；

阿裡在java後端領域支撐起全球通路量最大的伺服器叢集；

java代碼建構的阿裡雙11業務系統訂單處理能力達到17.5萬筆/秒；

到目前已累計數億行高并發、高穩定性的最佳java代碼實踐；

……

此次公開的java開發手冊正是出自這樣的團隊，近萬名阿裡java技術精英的經驗總結，并經曆了多次大規模一線實戰檢驗及完善，鑄就了這本高含金量的阿裡java開發手冊。該手冊以java開發者為中心視角，劃分為程式設計規約、異常日志規約、mysql規約、工程規約、安全規約五大塊，再根據内容特征，細分成若幹二級子目錄。根據限制力強弱和故障敏感性，規約依次分為強制、推薦、參考三大類。此套規範不僅能讓代碼一目了然，

更有助于加強團隊分工與合作、真正提升效率。 

<b></b>

<b>無規矩不成方圓</b>

無規範不能協作

衆所周知，制訂交通法規表面上是要限制行車權，實際上是保障公衆的人身安全。試想如果沒有限速，沒有紅綠燈，沒有規定靠右行駛，誰還敢上路行駛。 

同理，對軟體來說，适當的規範和标準絕不是消滅代碼内容的創造性、優雅性，而是限制過度個性化，以一種普遍認可的方式一起做事，降低故障率，提升協作效率。開發手冊詳細列舉如何開發更加高效，更加容錯，更加有協作性，力求知其然，更知其不然，結合正反例，提高代碼品質。比如，異常日志處理時的各種不規範行為；集合轉換的各種坑；建立線程池出現的等待隊列oom等。 

<b>阿裡技術資深大咖聯袂推薦</b>

<b>阿裡進階研究員多隆</b>：工程師對于代碼，一定要“精益求精”，不論從性能，還是簡潔優雅，都要具備“精益求精”的工匠精神，認真打磨自己的作品。 

<b>阿裡研究員畢玄</b>：一個優秀的工程師和一個普通工程師的差別，不是現在滿天飛的架構圖，他的功底就是展現在他寫的每一行代碼上。 

<b>阿裡研究員玄難</b>：代碼是軟體工程裡面的産品設計、系統架構設計等工作的最後承載體，代碼的品質決定了一切工作的成敗。 

<b>阿裡巴巴b2b事業群cto李純</b>：好的軟體産品離不開工程師高品質的代碼及互相間順暢的溝通與合作。簡單，适用的代碼規約背後所傳遞的是技術上的追求卓越、協同合作的精神，是每個技術團隊不可缺失的重要利器。 

<b>阿裡研究員、hiphop作者：趙海平（花名：福貝）</b>：程式員是創造個性化作品的藝術家，但同時也是需要團隊合作的工種。個性化應盡量表現在代碼效率和算法方面，犧牲小我，成就大我。 

<b>擁抱規範，遠離傷害！</b>

開發的同學們趕緊行動起來，遵守代碼規範，你好，我好，大家好！ 

關注雲栖社群微信公衆号：