之前因為助教工作閱讀過一遍《構建之法》，現在回頭重新翻看這本書，越發覺得這本書值得深入閱讀。本週先將前兩周的讀書筆記記錄如下：
第一章從淺入深，以航空業的發展歷程作為模型，模擬軟體工程的發展。玩具：紙飛機》業餘愛好：沙灘椅+氦氣球》探索：萊特兄弟》產業：容納百萬人就業的航空業。類似的，軟體也從簡單的「hello world」到寫**到構建乙個軟體系統的從簡到繁，從易到難的發展歷程。軟體=程式+軟體工程。軟體工程是什麼？書上是這麼說的：
軟體工程是把系統的、有序的、可量化的方法應用在軟體的開發、運營和維護上的工程。從這兩個公式可以看出，程式是基本功，軟體工程決定軟體質量，而商業模式就決定了乙個軟體企業的成敗。
軟體具有複雜性、不可預見性、易變性、服從性和非連續性的特點，如何「做乙個好軟體」既是軟體工程的目的，也是挑戰和魅力所在。
作為乙個工程師的宗旨是：我構建，故我在。好的工程師能儘量減少軟體的bug。bug的多少影響著軟體的使用者滿意度、可靠性、軟體流程的質量和可維護性。只要軟體的行為和使用者的期望不一致，就可以稱為bug。
通過系統闡述，《構建之法》的教學目標即為以下三點：
研發出符合使用者需求的軟體
通過一定流程，在預定時間內發布「足夠好」的軟體。
能證明所開發的軟體是可維護和繼續發展的
psp（personal software process)，個人軟體開發流程的任務清單如下所示：
作者對比了中科大大四學生和工作三年的工程師的psp**，結果表明工程師在「需求分析」和「測試」方面花了更多時間(多60%以上）。而在具體編碼上，工程師要比學生快的多（60%左右）
此外涉及到的內容由單元測試、回歸測試、效能分析。單元測試是保證模組質量的有效解決方案。好的單元測試應該準確、快速保證程式基本模組的正確性。好的單元測試有以下標準:
在最基本的功能/引數上驗證程式的正確性
由最熟悉的人來寫
單元測試後機器狀態保持不變
單元測試要快並產生可重複、一致的結果。
保證獨立性
覆蓋所有**路徑
所謂回歸測試（regression test)目的有二：
驗證新的**的確改正缺陷
驗證新的**有沒有破壞模組的現有功能，有沒有regression
regress:return to a worse or less developed state.回歸測試最好自動化，並且對每乙個bug fix都要進行回歸測試
效能分析目的是是找到程式的效能瓶頸進而可針對性優化程式。效能分析有兩個方法：抽樣和**注入。一般方法是先用抽樣找到瓶頸所在，再對特定模組用**注入方法詳細分析。
《構建之法》讀書筆記第3章
第三章講的是軟體工程師的發展。主要從軟體工程師的評價方法，團隊期望和技能的反面進行闡述，並對應的分為3個小節。在第一小節中講的是個人能力的衡量與發展。對於初級軟體工程師的成長，從以下5個方面開始 積累軟體開發相關的知識，提公升技術技能 積累問題領域的知識和經驗 例如 對醫療或金融行業的了解 對通用的...
構建之法第4 17章讀書筆記
第四章 兩人合作 問題1 4.2中注釋這一版塊，因為之前有學長跟我強調過 規範的問題，所以對這方面比較重視，後來當使用每個ide的時候，都會去注意 縮排的快捷鍵，比如idea的ctrl alt l等等 我對自己寫的 還算比較滿意，但是在注釋這一塊確毫無頭緒，不知道什麼是標準，以前看過標準的注釋，記得...
《構建之法》六 七章讀書筆記
第六章敏捷流程 盡早並持續地交付有價值的軟體以滿足顧客需求 敏捷流程歡迎需求的變化，並利用這種變化來提高使用者的競爭優勢 經常發布可用的軟體，發布間隔可以從幾周到幾個月，能短則短 業務人員和開發人員在專案開發過程中應該每天共同工作 以有進取心的人為專案核心，充分支援信任他們 無論團隊內外，面對面的交...