《阿里Java開發手冊》 | 設計規約 (完)
【強制】存儲方案和底層資料結構的設計獲得評審一致通過，並沉澱成為文件。
說明：有缺陷的底層資料結構容易導致系統風險上升，可擴展性下降，重構成本也會因歷史資料遷移和系統平滑過渡而陡然增加，所以，存儲方案和資料結構需要認真地進行設計和評審，生產環境提交執行後，需要進行 double check。
正例：評審內容包括存儲介質選型、表結構設計能否滿足技術方案、存取性能和存儲空間能否滿足業務發展、表或欄位之間的辯證關係、欄位名稱、欄位類型、索引等；資料結構變更(如在原有表中新增欄位)也需要進行評審通過後上線。
【強制】在需求分析階段，如果與系統交互的User超過一類並且相關的 UserCase 超過 5 個，使用用例圖來表達更加清晰的結構化需求。
【強制】如果某個業務對象的狀態超過 3 個，使用狀態圖來表達並且明確狀態變化的各個觸發條件。
說明：狀態圖的核心是對象狀態，首先明確對像有多少種狀態，然後明確兩兩狀態之間是否存在直接轉換關係，再明確觸發狀態轉換的條件是什麼。
正例：淘寶訂單狀態有已下單、待付款、已付款、待發貨、已發貨、已收貨等。比如已下單與已收貨這兩種狀態之間是不可能有直接轉換關係的。
【強制】如果系統中某個功能的調用鏈路上的涉及對象超過 3 個，使用時序圖來表達並且明確各調用環節的輸入與輸出。
說明：時序圖反映了一系列對象間的交互與協作關係，清晰立體地反映系統的調用縱深鏈路。
【強制】如果系統中模型類超過 5 個，並且存在復雜的依賴關係，使用類圖來表達並且明確類之間的關係。
說明：類圖像建築領域的施工圖，如果搭平房，可能不需要，但如果建造螞蟻 Z 空間大樓，肯定需要詳細的施工圖。
【強制】如果系統中超過 2 個對象之間存在協作關係，並且需要表示複雜的處理流程，使用活動圖來表示。
說明：活動圖是流程圖的擴展，增加了能夠體現協作關係的對象泳道，支持表示並發等。
【推薦】系統架構設計時明確以下目標：
- 確定系統邊界。確定系統在技術層面上的做與不做。
- 確定系統內模組之間的關係。確定模組之間的依賴關係及模組的宏觀輸入與輸出。
- 確定指導後續設計與演化的原則。使後續的子系統或模組設計在一個既定的框架內和技術方向上繼續演化。
- 確定非功能性需求。非功能性需求是指安全性、可用性、可擴展性等。
【推薦】需求分析與系統設計在考慮主幹功能的同時，需要充分評估異常流程與業務邊界。
反例：用戶在淘寶付款過程中，銀行扣款成功，發送給用戶扣款成功短信，但是支付寶入款時由於斷網演練產生異常，淘寶訂單頁面依然顯示未付款，導致用戶投訴。
【推薦】類在設計與實作時要符合單一原則。
說明：單一原則最易理解卻是最難實作的一條規則，隨著系統演進，很多時候，忘記了類設計的初衷。
【推薦】謹慎使用繼承的方式來進行擴展，優先使用聚合/組合的方式來實作。
說明：不得已使用繼承的話，必須符合里氏代換原則，此原則說父類能夠出現的地方子類一定能夠出現，比如，“把錢交出來”，錢的子類美元、歐元、人民幣等都可以出現。
【推薦】系統設計階段，根據依賴倒置原則，盡量依賴抽像類與接口，有利於擴展與維護。
說明：低層次模組依賴於高層次模組的抽象，方便系統間的解耦。
【推薦】系統設計階段，注意對擴展開放，對修改閉合。
說明：極端情況下，交付的程式碼是不可修改的，同一業務域內的需求變化，通過模組或類的擴展來實作。
【推薦】系統設計階段，共性業務或公共行為抽取出來公共模組、公共配置、公共類、公共方法等，在系統中不出現重複程式碼的情況。
說明：隨著程式碼的重複次數不斷增加，維護成本指數級上升。
【推薦】避免如下誤解:敏捷開發 = 講故事 + 編碼 + 發布。
說明：敏捷開發是快速交付迭代可用的系統，省略多餘的設計方案，摒棄傳統的審批流程，但核心關鍵點上的必要設計和文件沉澱是需要的。
反例：某團隊為了業務快速發展，敏捷成了產品經理催進度的藉口，系統中均是勉強能運行但像麵條一樣的程式碼，可維護性和可擴展性極差，一年之後，不得不進行大規模重構，得不償失。
【參考】設計文件的作用是明確需求、理順邏輯、後期維護，次要目的用於指導編碼。
說明：避免為了設計而設計，系統設計文件有助於後期的系統維護和重構，所以設計結果需要進行分類歸檔保存。
【參考】可擴展性的本質是找到系統的變化點，並隔離變化點。
說明：世間眾多設計模式其實就是一種設計模式即隔離變化點的模式。
正例：極致擴展性的標誌，就是需求的新增，不會在原有程式碼交付物上進行任何形式的修改。
【參考】設計的本質就是識別和表達系統難點。
說明：識別和表達完全是兩回事，很多人錯誤地認為識別到系統難點在哪裡，表達只是自然而然的事情，但是大家在設計評審中經常出現語焉不詳，甚至是詞不達意的情況。準確地表達系統難點需要具備如下能力：表達規則和表達工具的熟練性。抽象思維和總結能力的局限性。基礎知識體系的完備性。深入淺出的生動表達力。
【參考】程式碼即文件的觀點是錯誤的，清晰的程式碼只是文件的某個片斷，而不是全部。
說明：程式碼的深度調用，模組層面上的依賴關係網，業務場景邏輯，非功能性需求等問題是需要相應的文件來完整地呈現的。
【參考】在做無障礙產品設計時，需要考慮到：
- 所有可交互的控件元素必須能被 tab 鍵聚焦，並且焦點順序需符合自然操作邏輯。
- 用於登陸校驗和請求攔截的驗證碼均需提供圖形驗證以外的其它方式。
- 自定義的控件類型需明確交互方式。
正例：用戶登陸場景中，輸入框的按鈕都需要考慮 tab 鍵聚焦，符合自然邏輯的操作順序如下，“輸入用戶名，輸入密碼，輸入驗證碼，點擊登錄”，其中驗證碼實作語音驗證方式。如果有自定義標籤實作的控件設置控件類型可使用 role 屬性。
心得
看完這篇「設計規約」後，滿多都是觀念和理想；最主要的是在說在設計的初期，需要先設想到擴展性、架構設計、未來維護成本⋯等等之類的。
多看個幾遍，很多的設計和想法，有可能太過理想，要記住很多東西會被現實阻礙～。
結語
文章越看越多，技術越學越多，就會發現自己的不足；技術學到後面都會想要將基礎再重新在打得更加扎實。
以前在開發覺得理所當然的事情，例如：命名規則、命名規範，照著別人怎麼說就怎麼做的想法，並沒有好好去想為什麼要這樣設計和規範。
於是乎同事們推薦《阿里巴巴Java開發手冊》來做閱讀，書中提到種種規範《正確範例》、《錯誤範例》還有解釋定義說明；我相信在閱讀完這一系列後，一定會更加扎實且實在。
如對此書有興趣，建議去購買官方認證的書籍，給予官方支持。
註：如有侵權，通知即刪。
註：以上參考了
Alibaba-Java-Coding-Guidelines Github
Alibaba-Java-Coding-Guidelines English Version
