豆瓣讀書：https://book.douban.com/subject/1477390/
《Code Complete》2d ed，CC2
3.1 前期準備的重要性
- 降低風險
- 避免“解決了一個錯誤的問題”
- 避免採用的開發方法不符合軟件特點
- 程序員是軟件食物鏈的最後一環。產品經理挖出需求，架構師吃掉需求，設計師吃掉架構，而程序員則消化設計。
3.2 辨明你所從事的軟件的類型
- 三種典型的軟件項目類別
- 商業系統
- 使命有關的系統
- 性命攸關的嵌入式系統
- 適合序列式開發方法的特點
- 需求相當穩定
- 設計直截了當，而且理解透徹
- 開發團隊對於這一應用領域非常熟悉
- 項目的風險很小
- “長期可預測性”很重要
- 後期改變需求，設計和編碼的代價可能比較昂貴
- 適合迭代式開發方法的特點
- 需求並沒有被理解透徹，或是不穩定
- 設計很複雜、有挑戰性
- 開發團隊不熟悉這一應用領域
- 項目包含許多風險
- “長期可預測性”不重要
- 後期改變需求、設計和編碼的代價較低
3.3 問題定義的先決條件
- 問題定義應該用客戶的語言來書寫，而且應該從客戶的角度來描述問題，不應該使用計算機專業術語。
- 如果沒有明確的問題定義，那麼你可能會在構建期間解決錯誤的問題。
3.4 需求的先決條件
- 明確需求，無需再猜測用戶想要什麼。
- 需求變更在很多情況下無法完全避免，因爲開發過程幫助客戶更深入地了理解了自己的需求。
- 應對需求變更的方法
- 確保每一個人都知道需求變更的代價
- 建立一套變更控制流程
- 採用能適應變更的開發方法
- 放棄這個項目
- 對照需求覈對表進行檢查，確保需求已做好。
3.5 架構的先決條件
- 架構的典型組成部分
- 程序組織，系統結構
- 主要的類
- 數據設計
- 業務規則
- 用戶界面設計
- 資源管理
- 安全性
- 性能
- 可伸縮性
- 互用性（與其他系統交互）
- 國際化、本地化
- 輸入輸出
- 錯誤處理
- 容錯性
- 架構的可行性
- 過度工程（多做比必要的工作）
- 關於“買”還是“造”的決策
- 關於複用的決策
- 變更策略
- 架構的總體質量
- 對照架構覈對表進行檢查，確保架構已做好。
3.6 花費在前期準備上的時間長度
- 一般來說，一個運作良好的項目會在需求、架構以及其他前期計劃方面投入 10% - 20% 的工作量和 20% - 30% 的時間。
對照前期準備覈對表進行檢查，確保前期準備工作已做好：
2019-08-24