【強制】儲存方案和底層資料結構的設計獲得評審一致通過，並沉澱成為文件。
說明：有缺陷的底層資料結構容易導致系統風險上公升，可擴充套件性下降，重構成本也會因歷史資料遷移和系統平滑過渡而陡然增加，所以，儲存方案和資料結構需要認真地進行設計和評審，生產環境提交執行後，需要進行 double check。
正例：評審內容包括儲存介質選型、表結構設計能否滿足技術方案、訪問效能和儲存空間能否滿足業務發展、表或字段之間的辯證關係、欄位名稱、字段型別、索引等；資料結構變更（如在原有表中新增字段）也需要進行評審通過後上線。
【強制】在需求分析階段，如果與系統互動的 user 超過一類並且相關的 user case 超過 5 個，使用用例圖來表達更加清晰的結構化需求。
【強制】如果某個業務物件的狀態超過 3 個，使用狀態圖來表達並且明確狀態變化的各個觸發條件。
說明：狀態圖的核心是物件狀態，首先明確物件有多少種狀態，然後明確兩兩狀態之間是否存在直接轉換關係，再明確觸發狀態轉換的條件是什麼。
正例：**訂單狀態有已下單、待付款、已付款、待發貨、已發貨、已收貨等。比如已下單與已收貨這兩種狀態之間是不可能有直接轉換關係的。
【強制】如果系統中某個功能的呼叫鏈路上的涉及物件超過 3 個，使用時序圖來表達並且明確各呼叫環節的輸入與輸出。
說明：時序圖反映了一系列物件間的互動與協作關係，清晰立體地反映系統的呼叫縱深鏈路。
【強制】如果系統中模型類超過 5 個，並且存在複雜的依賴關係，使用類圖來表達並且明確類之間的關係。
說明：類影象建築領域的施工圖，如果搭平房，可能不需要，但如果建造螞蟻 z 空間大樓，肯定需要詳細的施工圖。
【強制】如果系統中超過 2 個物件之間存在協作關係，並且需要表示複雜的處理流程，使用活**來表示。
說明：活**是流程圖的擴充套件，增加了能夠體現協作關係的物件泳道，支援表示併發等。
【推薦】需求分析與系統設計在考慮主幹功能的同時，需要充分評估異常流程與業務邊界。
反例：使用者在**付款過程中，銀行扣款成功，傳送給使用者扣款成功簡訊，但是支付寶入款時由於斷網演練產生異常，**訂單頁面依然顯示未付款，導致使用者投訴。
【推薦】謹慎使用繼承的方式來進行擴充套件，優先使用聚合/組合的方式來實現。
說明：不得已使用繼承的話，必須符合黎克特制代換原則，此原則說父類能夠出現的地方子類一定能夠出現，比如，「把錢交出來」，錢的子類美元、歐元、人民幣等都可以出現。
12.【推薦】系統設計階段，共性業務或公共行為抽取出來公共模組、公共配置、公共類、公共方法等，避免出現重複**或重複配置的情況。
說明：隨著**的重複次數不斷增加，維護成本指數級上公升。
13.【推薦】避免如下誤解：敏捷開發 = 講故事 + 編碼 + 發布。
說明：敏捷開發是快速交付迭代可用的系統，省略多餘的設計方案，摒棄傳統的審批流程，但核心關鍵點上的必要設計和文件沉澱是需要的。
反例：某團隊為了業務快速發展，敏捷成了產品經理催進度的藉口，系統中均是勉強能執行但像麵條一樣的**，可維護性和可擴充套件性極差，一年之後，不得不進行大規模重構，得不償失。
16.【參考】系統架構設計的目的：
- 確定系統邊界。確定系統在技術層面上的做與不做。
- 確定系統內模組之間的關係。確定模組之間的依賴關係及模組的巨集觀輸入與輸出。
- 確定指導後續設計與演化的原則。使後續的子系統或模組設計在規定的框架內繼續演化。
- 確定非功能性需求。非功能性需求是指安全性、可用性、可擴充套件性等。
規約先行 （十八）應用分層
推薦 圖中預設上層依賴於下層，箭頭關係表示可直接依賴，如 開放介面層可以依賴於web 層，也可以直接依賴於 service 層，依此類推 dao 層 資料訪問層，與底層 mysql oracle hbase 等進行資料互動。外部介面或第三方平台 包括其它部門 rpc 開放介面，基礎平台，其它公司的 ...
軟體構造（4） 設計規約
一.行為等價性 根據規約判斷是否行為等價 單純的看實現 並不足以判定不同的implmentation是否是 行為等價的 需要根據 的spec 開發者與client之間形成的contract 判定行為等價性 在編寫 之前，需要弄清楚spec如何協商形成 如何撰寫 二.前置與後置條件 前置條件 對客戶端...
Python Signal 訊號 （二十一）
常用訊號型別sigint 終止程序 中斷程序，不可通過signal.signal 捕捉 相當於ctrl c sigterm 終止程序 軟體終止訊號，可通過signal.signal 捕捉 預設訊號，當os.kill 沒有指明訊號型別時，預設的是該訊號 sigkill 終止程序 殺死程序，不可捕捉 相...