三思而後行
[TOC]
本文設計到以下幾塊內容
- 軟體工程的生命週期
- 構建的幾個先決條件
- 問題的定義的先決條件
- 需求的先決條件
- 架構的先決條件
軟體工程的生命週期

如上圖所示是軟體工程的生命週期或者是軟體中某個迭代生命週期。構建活動一般滴被認為是包括詳細設計、編碼除錯、測試這些活動的集合。當然這張圖只是一個簡單大概的示例而已，實際軟體開發過程中的會涉及到更多的活動以及更多的參與者，並且每個活著的參與者不止是隻有一個。比如測試的步驟細分來說包含了單元測試、系統測試、整合、整合測試等步驟；規劃構建的活動可能是由專案經理、產品經理、專案主管等多個參與者共同決議的。
構建的幾個先決條件
整個軟體的生命週期可以看做是由各種活動以及活動參與者構成的食物鏈，鏈下游的活動和參與者會受到鏈上游的活動和參與者影響，每一級的參與者都會把上一級的任務具體化、細化、消化，以供給下一個參與者對應的活動。從食物鏈的角度看，食物鏈底端的參與者吃了受汙染的食物那麼勢必是會影響到食物鏈上端的參與者，構建活動也是類似的。如果構建活動的上游包括問題提出、需求分析、架構設計相關的活動除了差錯那麼到了構建活動糾正這些差錯的代價就會大得多了，比如需求出現了問題，可能導致下游的架構設計、詳細設計、編碼除錯、測試等一系列活動的變更和調整，需要花費更多的時間、人力去做這個調整，比起在需求分析活動中糾正這個錯誤，到了構建活動發現這個錯誤來說這個問題就顯得相對的致命了，所以這些構建活動的前期準備需要被認真加以對待的。
構建前期的活動包含了問題的定義、需求分析、構建設計，下面分別談論這些活動所需要的先決條件
問題的定義的先決條件
何為問題的定義，就是對要解決的問題作出清除的陳述，有以下幾個原則需要被遵守
- 問題的定義應該使用客戶的語言來書寫
- 最好的解決方案未必是一個計算機程式
- 例外的情況：解決的問題本身即是計算機有關的問題：編譯時間、BUG，這種情況是可以使用計算機語言描述的
- 未能定義問題的後果：浪費了大量的時間去解決錯誤的問題，這是雙重處罰，因為你為沒解決問題
為什麼需要遵循以上這些原則呢？還得從實際的軟體活動中來看的，比如我在開發過程中遇到一個問題是：Android平臺詳情頁中顯示長圖的效果比較模糊，這是因為Android平臺對圖片渲染使用的記憶體做了限制，長圖或者相對比較大的圖會被壓縮為比較小的圖片導致清晰度降低了很多。如果從技術角度看待這個問題，這個問題就會被描述為：“Android平臺的長圖顯示過於模糊，開發人員需要對長圖做優化”。前半句是問題描述、後半句是對應問題的解決方案，這是一個反面的例子，因為不止描述了問題，還包含了問題的解決方案，其實這個問題出現的概率是比較小的，可以通過運營手段來處理這個內容，比如長圖分割為多圖顯示、帶有圖文的長圖分解為圖文重新排版，這就可以解決該問題了。所以精確不帶方案的提出問題的意義其實是十分重大的，可以重新從多角度看待該問題，最終提出合理的解決方案，反之不嚴格的問題定義限制了方向，導致了最終問題的解決出現偏差。
需求的先決條件
為什麼
- 確保是使用者而不是程式猿駕馭系統的功能，不需要猜測使用者、客戶想要什麼
- 有助於避免爭論，可以檢視書面需求，以解決分歧
- 重視需求有助於減少表層開發之後的系統變更
在上面的構建的幾個先決條件也提到了這一點
怎麼做
需求變更是客觀存在的事實，25%的變革導致的返工佔到總量的70%-85%，處理需求的變革可以遵循的一些原則
- 核對表評估需求的質量，這是量化的標準
- 確保需求變更的代價、成本（需求變更會影響到需求-設計-編碼-測試等相關的活動和使用者文件）評估變更的待機是必要的，哪怕是看上去微不足道的變更
- 變更控制程式（你知道自己的需求在特定的時候處理變更，客戶知道你打算處理他們的提議）
- 設定需求變更的優先順序
- 控制需求變更
- 堤防大量的變更請求（表明需求、架構或者上層設計做的不夠好，從而無法有效的支援構建活動）
- 警惕官僚主義，醫藥害怕官僚主義而排斥有效的變更控制，在已有的計劃上引入了糟糕的變更控制會讓變更堆積如山，這種變更是具有破壞性的，體現在以下幾個方面
- 專案狀態的能見度
- 長期的可預見性
- 專案計劃
- 分享管理
- 專案管理
- 成組的處理變更請求
- 記錄下來，不管它實現起來有多容易，直到你有時間去處理它
- 把它當做整體來看待，從中 最有價值的變更加以實施
- 使用能適應變更的開發方法，合適的增量整合策略，功能導向的整合，其實目前在移動或者後端的開發框架總都有廣泛的使用到的
- 先完成框架、容器層以及底層共享元件
- 然後根據不同的功能完成中間的業務功能，實現分批互動
架構的先決條件
- 程式的組織
- 最終選用方案的理由
- 清晰的構思
- 定義程式的主要構造快<一種高層的功能>
- 使用者互動
- 顯示頁面
- 解釋命令
- 封裝業務規則
- 訪問資料
- 最小知識原則、高內聚低耦合原則
- 明確的通訊規則-物件的封裝藝術（隱藏細節以及提供訪問介面）
- 主要的類，80/20法則描述其中20%的主要的類以及設計理念
- 資料設計<包含主要檔案和資料表設計>
- 選擇的理由-設計理念以及架構思想以便之後的維護和擴充套件
- 定義訪問的方式或者抽象的訪問介面
- 詳細定義所用的資料的高層組織結構以及內容，單表或者多表的結構
- 資源管理
- 包含的資源：資料庫、執行緒、控制程式碼
- 估算在最壞情況和情況下的用量
- 安全性<資料或者通訊的加密和解密規則演算法>
- 效能
- 效能目標應該詳細定義資源（記憶體、速度、成本）的優先順序
- 效能目標的估算以及是否達成目標，如未達成有何影響和措施
- 是否有有使用了特定的演算法或者資料結構以達到特定的效能要求
- 錯誤處理
- 錯誤處理是否需要使用全域性
- 錯誤處理的約定，使用同一的方式處理方便維護
- 錯誤檢測是主動還是被動的<防禦性的措施>
- 錯誤在哪個層級上處理，結構層或者應用層，或者因情況而定
- 總體質量
- 概念的完整性，與解決的問題和諧一致，易於理解
- 描述所有主要決策的動機
- 儘量的做到與程式語言和環境的無關
- 架構應該處理所有的需求，同時不去鍍金
- 指出有風險的區域
- 多視角，有助於他人完整的理解系統的設計