七、設計規約

1.【強制】儲存方案和底層資料結構的設計獲得評審一致通過，並沉澱成為文件。

說明：有缺陷的底層資料結構容易導致系統風險上升，可擴充套件性下降，重構成本也會因歷史資料遷移和系統平滑過渡而陡然增加，所以，儲存方案和資料結構需要認真地進行設計和評審，生產環境提交執行後，需要進行 double check。

正例：評審內容包括儲存介質選型、表結構設計能否滿足技術方案、存取效能和儲存空間能否滿足業務發展、表或欄位之間的辯證關係、欄位名稱、欄位型別、索引等；資料結構變更（如在原有表中新增欄位）也需要進行評審通過後上線。

2.【強制】在需求分析階段，如果與系統互動的 User 超過一類並且相關的 User Case 超過 5 個，使用用例圖來表達更加清晰的結構化需求。

注：Use Case（用例）：對系統功能的描述，一個Use Case描述的是整個系統功能的一部        分，這一部分一定要是在邏輯上相對完整的功能流程。
3.【強制】如果某個業務物件的狀態超過 3 個，使用狀態圖來表達並且明確狀態變化的各個觸發條件。
    注：狀態圖(statechart diagram): 用來描述一個特定的物件所有可能的狀態,以及由於各種事件的發生而引起的狀態之間的轉移和變化。

說明：狀態圖的核心是物件狀態，首先明確物件有多少種狀態，然後明確兩兩狀態之間是否存在直接轉換關係，再明確觸發狀態轉換的條件是什麼。

正例：淘寶訂單狀態有已下單、待付款、已付款、待發貨、已發貨、已收貨等。比如已下單與已收貨這兩種狀態之間是不可能有直接轉換關係的。

4.【強制】如果系統中某個功能的呼叫鏈路上的涉及物件超過 3 個，使用時序圖來表達並且明確各呼叫環節的輸入與輸出。

說明：時序圖反映了一系列物件間的互動與協作關係，清晰立體地反映系統的呼叫縱深鏈路。

5.【強制】如果系統中模型類超過 5 個，並且存在複雜的依賴關係，使用類圖來表達並且明確類之間的關係。

說明：類影象建築領域的施工圖，如果搭平房，可能不需要，但如果建造螞蟻 Z 空間大樓，肯定需要詳細的施工圖。

6.【強制】如果系統中超過 2 個物件之間存在協作關係，並且需要表示複雜的處理流程，使用活動圖來表示。

說明：活動圖是流程圖的擴充套件，增加了能夠體現協作關係的物件泳道，支援表示併發等。
注：泳道將活動圖中的活動化分為若干組，並把每一組指定給負責這組活動的業務組織，通常為物件。https://www.cnblogs.com/jingwhale/p/4230235.html

7.【推薦】需求分析與系統設計在考慮主幹功能的同時，需要充分評估異常流程與業務邊界。反例：使用者在淘寶付款過程中，銀行扣款成功，傳送給使用者扣款成功簡訊，但是支付寶入款時由於斷網演練產生異常，淘寶訂單頁面依然顯示未付款，導致使用者投訴。

8.【推薦】類在設計與實現時要符合單一原則。

說明：單一原則最易理解卻是最難實現的一條規則，隨著系統演進，很多時候，忘記了類設計的初衷。
注：單一（職責）原則：將不同的職責分離到單獨的類，每一個職責都是一個變化的中心。一個類應該有且只有一個變化的原因。

9.【推薦】謹慎使用繼承的方式來進行擴充套件，優先使用聚合/組合的方式來實現。
    注：大雁與雁群的這種關係就可以稱之為聚合。雁翅與大雁的關係就叫做組合。大雁可以脫離雁群獨自生存。雁翅不能脫離大雁獨自生存。
說明：不得已使用繼承的話，必須符合里氏代換原則，此原則說父類能夠出現的地方子類一定能夠出現，比如，“把錢交出來”，錢的子類美元、歐元、人民幣等都可以出現。

10.【推薦】系統設計時，根據依賴倒置原則，儘量依賴抽象類與介面，有利於擴充套件與維護。

說明：低層次模組依賴於高層次模組的抽象，方便系統間的解耦。

11.【推薦】系統設計時，注意對擴充套件開放，對修改閉合。

說明：極端情況下，交付的程式碼都是不可修改的，同一業務域內的需求變化，通過模組或類的擴充套件來實現。

12.【推薦】系統設計階段，共性業務或公共行為抽取出來公共模組、公共配置、公共類、公共方法等，避免出現重複程式碼或重複配置的情況。

說明：隨著程式碼的重複次數不斷增加，維護成本指數級上升。

13. 【推薦】避免如下誤解：敏捷開發 = 講故事 + 編碼 + 釋出。

說明：敏捷開發是快速交付迭代可用的系統，省略多餘的設計方案，摒棄傳統的審批流程，但核心關鍵點上的必要設計和文件沉澱是需要的。

反例：某團隊為了業務快速發展，敏捷成了產品經理催進度的藉口，系統中均是勉強能執行但像麵條一樣的程式碼，可維護性和可擴充套件性極差，一年之後，不得不進行大規模重構，得不償失。

14.【參考】系統設計主要目的是明確需求、理順邏輯、後期維護，次要目的用於指導編碼。

說明：避免為了設計而設計，系統設計文件有助於後期的系統維護，所以設計結果需要進行分類歸檔儲存。

15.【參考】設計的本質就是識別和表達系統難點，找到系統的變化點，並隔離變化點。

說明：世間眾多設計模式目的是相同的，即隔離系統變化點。

16. 【參考】系統架構設計的目的：

確定系統邊界。確定系統在技術層面上的做與不做。

確定系統內模組之間的關係。確定模組之間的依賴關係及模組的巨集觀輸入與輸出。

確定指導後續設計與演化的原則。使後續的子系統或模組設計在規定的框架內繼續演化。

確定非功能性需求。非功能性需求是指安全性、可用性、可擴充套件性等。