阿里Java規範再次刷新代碼規範認知，新增的16條設計規約你瞭解嗎？

就在前不久，火熱進行的 「向代碼致敬，尋找你的第83行」 活動中參與人數衆多，各位程序員紛紛曬出本身的規範代碼，一絕高下，最終通過激烈角逐選出了兩位高手盲人程序員蔡永斌和高中生青藤木子，然而這些代碼的規範性評定標準就是《阿里巴巴Java開發手冊》，它是阿里內部Java工程師所遵循的開發規範，涵蓋編程規約、單元測試規約、異常日誌規約、MySQL規約、工程規約、安全規約等，這是近萬名阿里Java技術精英的經驗總結。

2018年6月5日，《阿里巴巴Java開發手冊》再次刷新代碼規範認知，新增了16條設計規約！

何爲16條？

設計規約是根據阿里巴巴實際項目架構經驗提煉而成，共16條。設計規約主要從UML圖和架構設計原則來規定比較基礎的軟件設計理念，而且明確了超過什麼樣的閾值須要以什麼樣的方式來呈現設計思惟。根據阿里巴巴內部的反饋聲音來看，對於數據底層結構、狀態圖、以及敏捷開發相關的三條，共鳴感最強，那麼詳細點評一下：

數據底層結構

底層數據結構屬於大廈的地基工程，若是地基不穩，那麼上層去修正難度是至關大的，甚至是沒法修正。因此設計規約提倡，存儲方案和底層數據結構的設計得到評審一致經過，並沉澱成爲文檔。有缺陷的底層數據結構容易致使系統風險高，可擴展性差，重構成本因歷史數據遷移、系統平滑過渡也會陡然增長，因此，存儲方案和數據結構須要認真地進行設計和評審，生產環境提交執行後，須要進行double check。評審內容包括存儲介質選型、表結構設計可否知足技術方案、存取性能和存儲空間可否知足業務發展、表或字段之間的辯證關係、字段名稱、字段類型、索引等；數據結構變動（如在原有表中新增字段）也須要進行評審經過後上線。

狀態圖

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