《建構之法》讀書筆記第1、2章

之前因為助教工作閱讀過一遍《建構之法》，現在回頭重新翻看這本書，越發覺得這本書值得深入閱讀。本周先将前兩周的讀書筆記記錄如下：

第一章 概論

第一章從淺入深，以航空業的發展曆程作為模型，類比軟體工程的發展。玩具：紙飛機>>業餘愛好：沙灘椅+氦氣球>>探索：萊特兄弟>>産業：容納百萬人就業的航空業。類似的，軟體也從簡單的“Hello World”到寫網站到建構一個軟體系統的從簡到繁，從易到難的發展曆程。軟體=程式+軟體工程。軟體工程是什麼？書上是這麼說的：

軟體工程是把系統的、有序的、可量化的方法應用在軟體的開發、營運和維護上的工程。

相對于大家廣而熟知的“程式=資料結構+算法”等式，對應的軟體=程式+軟體工程。而對于軟體企業來說，自然也可以推論出：

軟體企業=軟體+商業模式

從這兩個公式可以看出，程式是基本功，軟體工程決定軟體品質，而商業模式就決定了一個軟體企業的成敗。

軟體具有複雜性、不可預見性、易變性、服從性和非連續性的特點，如何“做一個好軟體”既是軟體工程的目的，也是挑戰和魅力所在。

作為一個工程師的宗旨是：我建構，故我在。好的工程師能盡量減少軟體的Bug。Bug的多少影響着軟體的使用者滿意度、可靠性、軟體流程的品質和可維護性。隻要軟體的行為和使用者的期望不一緻，就可以稱為Bug。

通過系統闡述，《建構之法》的教學目标即為以下三點：

1. 研發出符合使用者需求的軟體
2. 通過一定流程，在預定時間内釋出“足夠好”的軟體。
3. 能證明所開發的軟體是可維護和繼續發展的

第二章 個人技術和流程

PSP（Personal Software Process)，個人軟體開發流程的任務清單如下所示：

作者對比了中科大大四學生和工作三年的工程師的PSP表格，結果表明工程師在“需求分析”和“測試”方面花了更多時間(多60%以上）。而在具體編碼上，工程師要比學生快的多（60%左右）

此外涉及到的内容由單元測試、回歸測試、效能分析。單元測試是保證子產品品質的有效解決方案。好的單元測試應該準确、快速保證程式基本子產品的正确性。好的單元測試有以下标準:

1. 在最基本的功能/參數上驗證程式的正确性
2. 由最熟悉的人來寫
3. 單元測試後機器狀态保持不變
4. 單元測試要快并産生可重複、一緻的結果。
5. 保證獨立性

6. 覆寫所有代碼路徑

   所謂回歸測試（Regression Test)目的有二：

7. 驗證新的代碼的确改正缺陷

8. 驗證新的代碼有沒有破壞子產品的現有功能，有沒有Regression

   Regress:return to a worse or less developed state.回歸測試最好自動化，并且對每一個Bug Fix都要進行回歸測試

效能分析目的是是找到程式的效能瓶頸進而可針對性優化程式。效能分析有兩個方法：抽樣和代碼注入。一般方法是先用抽樣找到瓶頸所在，再對特定子產品用代碼注入方法詳細分析。