1. 【強制】存儲方案和底層數據結構的設計獲得評審一致通過，并沉淀成為文檔。 說明：有缺陷的底層數據結構容易導致系統風險上升，可擴展性下降，重構成本也會因歷史數據遷移和系 統平滑過渡而陡然增加，所以，存儲方案和數據結構需要認真地進行設計和評審，生產環境提交執行后， 需要進行 double check。 正例：評審內容包括存儲介質選型、表結構設計能否滿足技術方案、存取性能和存儲空間能否滿足業務發 展、表或字段之間的辯證關系、字段名稱、字段類型、索引等；數據結構變更（如在原有表中新增字段） 也需要進行評審通過后上線。 2. 【強制】在需求分析階段，如果與系統交互的 User 超過一類并且相關的 User Case 超過 5 個，使用用例圖來表達更加清晰的結構化需求。 3. 【強制】如果某個業務對象的狀態超過 3 個，使用狀態圖來表達并且明確狀態變化的各個觸 發條件。 說明：狀態圖的核心是對象狀態，首先明確對象有多少種狀態，然后明確兩兩狀態之間是否存在直接轉換 關系，再明確觸發狀態轉換的條件是什么。 正例：淘寶訂單狀態有已下單、待付款、已付款、待發貨、已發貨、已收貨等。比如已下單與已收貨這兩 種狀態之間是不可能有直接轉換關系的。 4. 【強制】如果系統中某個功能的調用鏈路上的涉及對象超過 3 個，使用時序圖來表達并且明 確各調用環節的輸入與輸出。 說明：時序圖反映了一系列對象間的交互與協作關系，清晰立體地反映系統的調用縱深鏈路。 5. 【強制】如果系統中模型類超過 5 個，并且存在復雜的依賴關系，使用類圖來表達并且明確 類之間的關系。 說明：類圖像建筑領域的施工圖，如果搭平房，可能不需要，但如果建造螞蟻 Z 空間大樓，肯定需要詳細 的施工圖。 6. 【強制】如果系統中超過 2 個對象之間存在協作關系，并且需要表示復雜的處理流程，使用 活動圖來表示。 說明：活動圖是流程圖的擴展，增加了能夠體現協作關系的對象泳道，支持表示并發等。 7. 【推薦】需求分析與系統設計在考慮主干功能的同時，需要充分評估異常流程與業務邊界。 反例：用戶在淘寶付款過程中，銀行扣款成功，發送給用戶扣款成功短信，但是支付寶入款時由于斷網演 練產生異常，淘寶訂單頁面依然顯示未付款，導致用戶投訴。 8. 【推薦】類在設計與實現時要符合單一原則。 說明：單一原則最易理解卻是最難實現的一條規則，隨著系統演進，很多時候，忘記了類設計的初衷。 9. 【推薦】謹慎使用繼承的方式來進行擴展，優先使用聚合/組合的方式來實現。 說明：不得已使用繼承的話，必須符合里氏代換原則，此原則說父類能夠出現的地方子類一定能夠出現， 比如，“把錢交出來”，錢的子類美元、歐元、人民幣等都可以出現。 10. 【推薦】系統設計時，根據依賴倒置原則，盡量依賴抽象類與接口，有利于擴展與維護。 說明：低層次模塊依賴于高層次模塊的抽象，方便系統間的解耦。 11. 【推薦】系統設計時，注意對擴展開放，對修改閉合。 說明：極端情況下，交付線上生產環境的代碼都是不可修改的，同一業務域內的需求變化，通過模塊或類 的擴展來實現。 12. 【推薦】系統設計階段，共性業務或公共行為抽取出來公共模塊、公共配置、公共類、公共 方法等，避免出現重復代碼或重復配置的情況。 說明：隨著代碼的重復次數不斷增加，維護成本指數級上升。 13. 【推薦】避免如下誤解：敏捷開發 = 講故事 + 編碼 + 發布。 說明：敏捷開發是快速交付迭代可用的系統，省略多余的設計方案，摒棄傳統的審批流程，但核心關鍵點 上的必要設計和文檔沉淀是需要的。 反例：某團隊為了業務快速發展，敏捷成了產品經理催進度的借口，系統中均是勉強能運行但像面條一樣 的代碼，可維護性和可擴展性極差，一年之后，不得不進行大規模重構，得不償失。 14. 【參考】系統設計主要目的是明確需求、理順邏輯、后期維護，次要目的用于指導編碼。 說明：避免為了設計而設計，系統設計文檔有助于后期的系統維護和重構，所以設計結果需要進行分類歸 檔保存。 15. 【參考】設計的本質就是識別和表達系統難點，找到系統的變化點，并隔離變化點。 說明：世間眾多設計模式目的是相同的，即隔離系統變化點。 16. 【參考】系統架構設計的目的： ? 確定系統邊界。確定系統在技術層面上的做與不做。 ? 確定系統內模塊之間的關系。確定模塊之間的依賴關系及模塊的宏觀輸入與輸出。 ? 確定指導后續設計與演化的原則。使后續的子系統或模塊設計在規定的框架內繼續演化。 ? 確定非功能性需求。非功能性需求是指安全性、可用性、可擴展性等。 17. 【參考】在做無障礙產品設計時，需要考慮到： ? 所有可交互的控件元素必須能被 tab 鍵聚焦，并且焦點順序需符合自然操作邏輯。 ? 用于登陸校驗和請求攔截的驗證碼均需提供圖形驗證以外的其它方式。 ? 自定義的控件類型需明確交互方式。