## 第三章 三四而后行:前期準備
> // checklist For Architecture
> 核對表：架構
### 針對各架構主題
- 程序的整體組織結構是否清晰？是否包含一個良好的架構全局觀（及其理由）？
- 是否明確定義了主要的構造塊(包括每個構造塊的職責范圍及與其他構造塊的接口)?
- 是否明顯涵蓋了“需求”中列出的所有功能（每個功能對應的構造塊不太多也不太少）？
- 是否描述并論證了那些最關鍵的類？
- 是否描述并論證了數據設計？
- 是否詳細定義了數據庫的組織結構和內容？
- 是否指出了所用關鍵的業務規則，并描述其對系統的影響？
- 是否描述了用戶界面設計的策略？
- 是否將用戶界面模塊化,使界面的變更不會影響程序其余部分？
- 否估算了稀缺資源（如線程、數據庫連接、句柄、網絡帶寬等）的使用量，是否描述并論證了資源管理的策略？
- 是否描述了架構的安全需求？
- 架構是否為每一個類、每一個子系統、或每一個功能域（functionality area）提出空間和時間預算？
- 架構是否描述了如何達到可伸縮性？
- 架構是否關注互操作性？
- 是否描述了國際化/本地化的策略？
- 是否提供了一套內聚的錯誤處理策略？
- 是否規定了容錯的辦法（如果有需要）？
- 是否證實了系統各個部分的技術可行性？
- 是否詳細描述了過度工程(overengineering)的方法？
- 是否包含了必要的“買 vs. 造”的策略？
- 架構是否描述了如何加工被復用的代碼，使之符合其他架構目標？
- 是否將架構設計得能夠適應很可能出現的變更？
### 架構的總體質量
- 架構是否解決了全部需求？
- 有沒有那個部分是“過度架構”或“欠架構（underarchitected）”？是否明確宣布了在這方面的預期指標？
- 整個架構是否在概念上協調一致？
- 頂層設計是否獨立于實現它的機器和語言？
- 是否說明了所有主要的決策的動機？
- 你，作為一名實現該系統的程序員，是否對這個系統的架構感覺良好？
### 中文要點：
- 構建活動的準備工作的根本目標在于降低風險。要確認你的準備活動是在降低風險，而非增加風險.
- 如果你想開發高質量的軟件，軟件開發過程必須由始至終關注質量。在項目初期關注質量，對產品質量的正面影響比在項目末期關注質量的影響要大。
- 程序員的一部分工作是教育老板和合作者，告訴他們軟件開發過程，包括在開始編程之前進行充分準備的重要性。
- 你所從事的軟件項目的類型對構建活動的前期準備有重大影響——許多項目應該是高度迭代式的，某些應該是序列式的。
- 如果沒有明確的問題定義，那么你可能會在構建期間解決錯誤的問題。
- 如果沒有做完良好的需求分析工作，你可能沒能察覺待解決的問題的重要細節。如果需求變更發生在構建之后的階段，其代價是“在項目早期更改需求”的 20至 100 倍。因此在開始編程之前，你要確認“需求”已經到位了。
- 如果沒有做完良好的架構設計，你可能會在構建期間用錯誤的方法解決正確的問題。架構變更的代價隨著“為錯誤的架構編寫的代碼數量”增加而增加，因此，也要確認“架構”已經到位了。
- 理解項目的前期準備所采用的方法，并相應地選擇構建方法。
### English Key Points：
- The overarching goal of preparing for construction is risk reduction. Be sure your preparation activities are reducing risks, not increasing them.
- If you want to develop high-quality software, attention to quality must be part of the software-development process from the beginning to the end. At tention to quality at the beginning has a greater influence on product quality than attention at the end.
- Part of a programmer’s job is to educate bosses and coworkers about the software-development process,including the importance of adequate preparation before programming begins.
- The kind of project you’re working significantly affects construction prerequisites—many projects should be highly iterative, and some should be more sequential.
- If a good problem definition hasn’t been specified, you might be solving the wrong problem during construction.
- If a good requirements work hasn’t been done, you might have missed important details of the problem.Requirements changes cost 20 to 100 times as much in the stages following construction as they do earlier, so be sure the requirements are right before you start programming.
- If a good architectural design hasn’t been done, you might be solving the right problem the wrong way during construction. The cost of architectural changes increases as more code is written for the wrong architecture, so be sure the architecture is right too.
- Understand what approach has been taken to the construction prerequisites on your project and choose your construction approach accordingly.
