第二章：個人技術和流程
要點： 單元測試，回歸測試，效能分析，基于個體的軟件開發流程(PSP)
單元測試的構建標準：
- 應當驗證基本的組件，典型的就是類
- 應當由程序編寫者編寫測試
- 測試過后機器狀態不變，測試過程中的變化必須在完成后恢復，比如將生成的文件刪除（這就是tearDown方法要做的事情）
- 測試要快
- 可重復、結果一致
- 獨立性， 不依賴于其他測試單元的成敗性。為此，可以人為構造一個對象或者數據
- 應當覆蓋所有的代碼路徑
- 應當集成到自動測試框架之中
- 單元測試必須和產品一起維護，保持同步
回歸測試：在單元測試的基礎上，當新版本發布時，工程師必須再次運行所有的測試。
效能分析：使用效率分析工具對代碼進行抽樣和注入兩種形式的分析，先進行抽樣調查，找到性能瓶頸代碼，然后使用注入分析瓶頸代碼塊，進行優化。
PSP
- 計劃
-- 估計任務需要花費的時間 - 開發
-- 分析需求
-- 生成設計文檔
-- 設計復審（和同事復審）
-- 代碼規范（為開發制定合適的規范）
-- 具體設計
-- 具體編碼
-- 代碼復審
-- 測試 - 記錄用時
- 測試報告
- 計算工作量
- 事后總結
- 提出過程改進計劃
第四章 兩人合作、代碼復審...
這一部分有關于C++代碼規范、通用代碼風格、通用代碼復審的說明
注釋： 應當說明代碼做什么以及為什么，而不是怎么做（How）。
(Bad)How：
// loop starts i from 0 to len, in each step, it does something
for(int i=0;i<len;i++)
{
doSomething(i);
}
上述注釋不好的原因是，它說明了代碼的執行流程，但是對于實際的作用卻沒有任何說明，相反，良好的注釋應當如下：
// transfer the array into a list
for(int i=0;i<len;i++)
{
doSomething(i);
}
復審
形式：自我復審、同伴復審、團隊復審(團隊vs開發者)
復審的基本含義：1.代碼符合代碼規范的框架 2.代碼解決了問題
基本步驟：1.保證所有的代碼能通過統一的警告級別（如gcc -W1|2|3）...
代碼復審的基本工具：元注釋
在代碼中出現 // TODO 形式的注釋，這些注釋適用于代碼復審的，并且有一些要求：
- 在發布階段，// TODO , // BUG 應當被消除
- 在復審階段， // REVIEW 應當被消除或者標記
第八章： 需求分析
軟件需求的劃分：1.功能性需求，說明軟件應當完成的功能 2.產品開發過程的需求，需要在某種約束條件下完成，比如時間，金錢 3.非功能性需求，也稱QoS，規定完成功能的時間或者其他約束 4.總和需求，多個模塊一起工作的需求
計劃和估計：必須對計劃進行合理的時間估計
第九章：PM -- 項目經理
Project Manager v.s. Program Manager
早期軟件開發過程中，內部交流的代價隨著人員的增加而急劇上升。PM的出現就是為了解決交流的問題。
現在，PM主要具有以下功能：
1.和客戶交談，組織用戶調查，發現用戶需求
2.了解和比較競爭產品
3.怎樣讓軟件變得可用、有用
4.改進團隊流程
簡言之，PM做除開發和測試之外的所有事情
第十章 典型用戶和場景
第一種分析方法： 分析典型用戶，分析典型用戶涉及的典型場景
第二種分析方法：Use Case， 即用戶用例
第三種方法：規格說明書，包括軟件功能說明書和軟件技術說明書
為了寫好功能說明書，必須先定義好一些概念。
