標籤：style color os io 使用 strong ar for 資料
第3章 Measure Twice, Cut Once:Upstream Prerequisities 三思而後行：前期準備
- 3.1 前期準備的重要性
- 3.2 辨明你所從事的軟體的類型
- 3.3 問題定義的先決條件
3.1 Importance of Prerequisites 前期準備的重要性如果你在項目的末期強調品質，那麼你會強調系統測試。但是測試只是完整的品質保證策略的一部分，而且不是最有影響的部分。測試是不可能檢查出諸如：“製造了一個錯誤的產品”，或者“使用錯誤的方法製造正確的產品”之類的缺陷的。這樣的缺陷在測試之前解決——更確切地說是在構建活動之間。如果你在項目中期強調品質，那麼你就會強調構建實踐。這些實踐是本書絕大部分篇幅的關注點如果你在項目的開始階段強調品質，那麼你就會計劃、要求並且設計一個高品質的產品。
- Do Prerequisites Apply to Modern Software Projects
前期準備適用於現代軟體項目嗎有些人斷言，諸如架構、設計及專案規劃等前期工作對於軟體項目來說是毫無用處的。總體來說，沒有哪項研究（無論過去還是仙子阿）支援這一斷言，最近的資料也不支援這一斷言。準備工作的中心目標就是降低風險：一個好的專案規劃者能夠儘可能早地將主要的風險清除掉，以使大部分工作能夠儘可能平穩地進行。目前，軟體開發中最常見的項目風險是糟糕的需求分析和糟糕的專案計劃，因此準備工作就傾向於集中改進需求分析和專案規劃。
- Causes Of IncompletePreparation
準備不周全的誘因造成準備工作不充分的一個常見的原因是，那些分配去做前期準備活動的開發人員並不具備完成這一任務的專業技能。當開發人員不知道如何進行這些前期工作的時候，建議“做更多的前期工作”就完全沒有用：如果不能首先把這項工作做好，那麼做再多也沒有意義！有一些程式員確實知道如何進行前期工作，但是他們並沒有做，因為他們不能夠抵抗“儘快開始編碼”的慾望。如果你也是這樣，我有兩條建議：第一：閱讀下一節中的爭論，它也許能告訴你一些你以前沒有想到的問題；第二，注意一下你經曆過的問題。只需要做幾個大項目，你就能體會到：事先做好計劃能避免很多壓力。程式員不做準備工作的最後一個原因是，管理者們隊那些“花時間進行構建活動的前期準備的程式員”的冷漠已經到了人神公憤的程度。你可以期望，管理著們應該已經開始明白：軟體開發不僅僅是寫代碼。
- Utterly Compelling and Foolproof Argument for Doing Prerequisites Before Construction
關於開始構建之前要做前期準備的絕對有力且簡明的論據
Appeal to Logic 訴諸邏輯進行有效編程的要領之一是：準備工作很重要。在開始做一個大項目之前，應該為這個項目制定計劃，這是很有意義的。從管理的角度看，做計劃意味著確定項目所需要用的時間、人數以及電腦台數。從技術角度講，做計劃意味著弄清楚你想要建造的是什麼，以防止浪費錢去建造錯誤的東西。有時候使用者在一開始並不完全清楚自己想要的是什麼，因此值得花費比理想情況下更多的力氣，找出他們真正想要的東西。但這至少比“先做一個錯誤的東西出來，然後扔掉，並從頭來過”的成本要低廉在開始動手製作這個系統之前，先好好思考打算如何去做，這也非常重要。你總部希望花費很多的時間和金錢，卻毫無必要地走進死胡同（尤其當這樣做會增加成本的時候）
Appeal to Analogy 訴諸類比程式員是軟體食物鏈的最後一環。架構師吃掉需求，設計師吃掉架構，而程式員則消化設計。
Appeal to Data 訴諸資料過去25年來的研究確鑿地證明了，在一開始就把事物做好是最合算的。進行非必要的改動的代價是高昂的。
Boss-Readiness Test “老闆就緒”測試如果你的老闆已經明白了“在開始構建之前進行前期準備”的重要性，那麼試試以下的測試，以確保他確實明白了。下面的句子哪些是自我實現的語言（sel-fulfilling prophecies）
- 我們最好立刻開始編碼，因為將會有很多的調試工作需要去做。
- 我們並沒有為測試安排太多的時間，因為將來不會發現多少缺陷
- 我們已經非常詳細地研究了需求和設計，我想不出在編碼和調試期間還會遇到什麼大的問題
上面這些陳述都是自我實現的語言，要瞄準最後那個。3.2 Determine the Kind of Software You‘re Working on 辨明你所從事的軟體的類型
| 軟 件 種 類 |
| |
商業系統 |
使命攸關的系統 |
性命攸關的嵌入式系統 |
| 典型應用 |
Internet網站
Intranet網站
庫存管理
遊戲
遊戲
管理資訊系統(MIS)
工資系統 |
嵌入式軟體
遊戲
Internet網站
盒裝軟體
軟體工具
Web service |
航空軟體
嵌入式軟體
醫療設備
作業系統
盒裝軟體 |
| 生命週期模型 |
敏捷開發（極限編程,Srum, time-box, 開發等等）
漸進原型(prototyping) |
分階段交付
漸進交付
螺旋式開發 |
分階段交付
螺旋式開發
漸進交付 |
| 計劃與管理 |
增量式專案計劃
隨需測試與QA計劃
非正式的變更控制 |
基本的預先計劃
基本的測試計劃
隨需QA計劃
正式的變更控制 |
充分的預先計劃
充分的測試計劃
充分的QA計劃
嚴格的變更控制 |
| 需求 |
非形式化的需求規格 |
半形式化的需求
隨需的需求評審 |
形式化的需求規格
形式化的需求檢查 |
| 設計 |
設計與編碼時結合的 |
架構設計
非形式化的詳細設計
隨需的設計評審 |
架構設計
形式化的架構檢查
形式化的詳細設計
形式化的詳細設計檢查 |
| 構建 |
結對程式設計或獨立編碼
非正式的check-in手續或沒有check-in手續 |
結對程式設計或獨立編碼
非正式的check-in
隨需程式碼檢閱 |
結對程式設計或獨立編碼
正式的check-in手續
正式的代碼檢查 |
| 測試與QA |
開發人員測試自己的代碼
測試先行開發
很少或沒有測試（由單獨的測試小組來做） |
開發人員自己測試自己的代碼
測試先行開發
單獨的測試小組 |
開發人員測試自己的代碼
測試先行開發
單獨的測試小組
單獨的QA小組 |
| 部署 |
非正式的部署過程 |
正式的部署過程 |
正式的部署過程 |
- Iterative Approaches‘ Effect on Prerequisites
反覆式開發法對前期準備的影響迭代方法往往能夠減少“前期準備不足”造成的負面影響，但是它不能完全消除次影響。
- Choosing Between Iterative and Sequential Approaches
在序列式開發法和迭代式開發法之間做出選擇你可能因為下列原因選擇一個更加序列化的方法
- 需求相當文檔
- 設計直接了當,而且理解透徹
- Team Dev對於這一應用領域非常熟悉
- 項目的風險很小
- "長期可預測性"很重要
- 後期改變需求、設計和編碼的代價可能較昂貴
你可能因為下列原因選擇一個更加迭代(as you go,走著瞧)的方法
- 需求並沒有被理解透徹,或者處於其他理由你認為它是不穩定的
- 設計很複雜,或者有挑戰性,或者兩者兼具
- Team Dev對於這一應用領域不熟悉
- 項目包含許多風險
- “長期可預測性”不重要
- 後期改變需求，設計和編碼的代價很可能較低
事實上，在軟體開發中，適用反覆式開發法法的情況比使用序列開發法的情況多得多。你應該首先確定哪些前期準備活動適合你的項目。有些項目在前期準備上面花的時間太少了，結果使得在構建活動中遇到大量不必要的反覆修改，同時阻礙了項目的穩步前進。有些項目則預先作了太多的事情，固執地堅持原有的需求和計劃，後來事實證明這些需求和計劃是無效的，這同樣阻止了構建活動的順利進展。3.3 Problem-Definition Prerequisite 問題定義的先決條件在開始構建之前，首先要滿足的一項先決條件是，對於這個系統要解決的問題作出清楚的陳述問題定義應該用客戶的語言來書寫，而且應該從客戶的角度來描述問題。通常不應該用電腦的專業術語敘述。這條規則也有例外，那就是解決的就是與電腦本身相關的問題：編譯時間太長，或者開發工具bug太多。這種情況下使用電腦術語或程式員術語來陳述問題是恰當的。"未能定義問題"的處罰是，你浪費了大量時間去解決錯誤的問題。這是雙重處罰，因為你也沒有解決正確的問題
第3章三思而後行：前期準備上（代碼大全7）
