第三章 三思而後行:前期的前置作業

Measure twice, cut once.

建構活動差不多佔整個專案成本的 65% 。

那什麼是建構活動?請直接看第五章,本章節討論的是前置作業。

3.1 前置作業的重要性

測試不可能檢查出諸如「製造了一個錯誤的產品」,或「使用錯誤的方法製造正確的產品」之類的缺陷。

如果你在專案開始階段強調品質,那你就會做計畫、要求並且設計一個高品質的產品。

前置工作的核心目標就是要降低風險:一個好的專案規劃者能夠儘早將主要的風險清除,以使專案的大部分工作能夠盡可能平穩地進行。

目前軟體開發中最常見這的專案風險

  • 糟糕的需求分析
  • 糟糕的專案計畫

準備不周的誘因

  • 沒有相關技術
  • 想趕快寫程式
  • 對前置作業不夠重視

建構之前要先做簡明且強而有力論據的前置作業

實現一個系統前,你需要理解「這個系統應該做些什麼」以及「它該如何做到這些」。

3.2 確認你所從事的軟體類型

3.3 問題定義的先決條件

在開始建構之前,首先要滿足的一項先決條件是「對這個系統要解決的問題做出清楚的陳述」。 「問題定義」只定義了「問題是什麼」,不涉及任何可能的解決方案。 問題定義應該用客戶的語言來書寫,而且應該從客戶的角度來描述問題。

如果沒有一個良好的問題定義,你努力解決的可能是一個錯誤的問題。

3.4 需求的先決條件

明確的需求有助於確保使用者能夠駕馭系統

在建構期間處理需求變動

  • 確保需求的品質,如果不夠明確不夠好,那就確認需求才能繼續下去
  • 建立一套變更控制程序
  • 使用能適應變化的開發方法
  • 注意專案的商業案例

3.5 架構的先決條件

軟體架構(software architecture)是軟體設計的高層次(high-level)部分,用於支撐更細節的設計框架。

為什麼要把架構當作是前置作業呢?因為架構的品質決定了系統的「概念完整性」

一個複雜的系統,會是由許多有「概念完整性」的子系統所組成。 舉例來說,我們要做一個銀行系統。 他可能是有許多擁有概念完整性的子系統組合而成。比如說:存款(取款)、貸款、外匯等等。

典型的架構組成部分

為什麼要設計? 為什麼要這樣設計?

程式組織

系統架構首先需要以概述(overview)的方式,對系統做一個描述。 如果沒有這種整體概念,你就無法理解你正在開發的那個類別對系統有何貢獻?

架構應該定義出程式的主要架構塊(building blocks)。 明確的定義各個構造塊的責任。每個構造塊應該負責某一個區域的事情。 並對其他構造塊所負責的區域知道越少越好。

主要的類別

架構應該詳細定義所使用的主要類別

  • 責任
  • 介面
  • 繼承體系
  • 狀態轉換
  • 物件持久化

如果系統夠大,要將多個類別組織成子系統 架構無需詳細說明系統中的每一個類別。(詳細說明 20% 的類別,這些類別會構成 80% 的系統行為)

資料設計

架構應該描述所用到的主要檔案和資料表的設計。 舉例來說:要維護一個客戶 ID 的列表,為什麼選用 sequential-access list 而不是其他種類。 資料通常應該只由一個子系統或是一個類別直接存取

業務規則

如果架構依賴於特定的業務規則,那麼它就應該詳細描述這些規則,並描述這些規則對系統設計的影響。

錯誤處理

最好從架構層次上來看待錯誤處理,以下有一些需要考量的事:

  • 錯誤處理事進行更正還是只進行檢測? 更正 -> 從錯誤中回覆 -> 告知使用者偵測到一個錯誤 檢測 -> Logging -> 告知使用者偵測到一個錯誤
  • 錯誤檢測是主動的還是被動的?
  • 程式如何傳播錯誤?
  • 錯誤訊息的處理有什麼約定?
  • 如何處理例外 (exceptions)
  • 在程式中,在什麼層次上處理錯誤?
  • 每個類別在驗證輸入資料的有效性方面,需要負何中責任?
  • 你希望用執行環境內建的錯誤處理機制,還是想建立一套屬於自己的機制?

架構的總體品質

好的架構設計應該與待解決的問題和諧一致

架構應該描述所有主要決策的動機。慎防「我們一直都這麼做」這種概念。 架構應該明確地址出有風險的區域。它應該解釋為什麼這些區域是有風險的,並說明已經採取了哪些步驟以使風險最小化。