0. 說明
我覺得把書上已經有的東西抄一遍到部落格上，對于學習幫助不大。我想了個辦法，把每個知識塊用一句話加以提煉，每次看到這句話，都把相關的知識在腦中快速再現一遍，作為檢驗。如果回想不起來，就去重新學習。多次再現成功之後，知識轉為長期記憶，就把這些話再作為一個知識塊提煉成一句話。如此疊代，書可以越讀越薄。
心得與評論的豐富度，除了和書本的知識量有關系之外，我覺得還和我自己已有的“相關知識”的量有關，因為知識隻有通過聯結才能活起來，心中有底才能說得出話。是以有些章節我沒寫什麼評論，說明我沒有新想法，隻是在積累知識“學習一個”而已。
1. 概論
知識要點：
航空業和軟體業的類比，商業與業餘軟體的差別，軟體工程大緻領域，軟體複雜性的來源，什麼是工程，怎樣的軟體才算好。
1.1 軟體 = 程式 + 軟體工程
實際上從産業規律來看，先驅探索應該放在成熟産業之後，畢竟能戰鬥在一線的都是化用規則于無形的巨佬。
商用軟體與業餘軟體的差別在于，商用軟體需要確定符合需求、功能齊備、可以維護、萬無一失。但是，企業的能力是有限的，軟體bug是無窮的。就算是微軟的OS也在一直打更新檔不是麼？是以其中的取舍，确是一門學問。
1.2 軟體工程是什麼
軟體的複雜度，随代碼量指數增長。
軟體的複雜度，本質不在技術而在管理。軟體工程的工具能夠幫助降低便攜軟體的難度，當一個軟體工程師的代碼量達到瓶頸後，他就知道應該使用更強力的軟體工程工具了。
2. 個人技術和流程
知識要點：單元測試，回歸測試，抽樣，代碼注入，效能分析工具的用法，psp。
2.1 單元測試
單元測試就是一堆的測試函數，是一堆的用例。我直接把這種函數和普通函數放在一起，每次跑程式的時候順便測試一下。單元測試顯然更規範，更靈活了，但是也就那麼回事。
回歸測試，概念類似“回檔”。子產品的版本，就像一棵樹，應該可以用github管理，但是我現在還不怎麼會用，也沒遇到過這麼複雜的情況。現在我最多隻會保留一個備份而已。
2.2 效能分析工具
選個名額，比如說記憶體吧，分析一下，發現某個函數特别消耗資源，改它，資源消耗量将下來了。這就是用效能分析工具進行優化，理論上特别簡單。當然，性能不是一切，不能為了性能犧牲代碼的可維護性。
2.3 個人開發流程
是個檢核表，好用。現在我對其中各項的了解還不夠，是以我準備了一個秒表，做什麼事情都計時，最後再看看什麼任務屬于什麼項目，再加進去。當然，這樣就很難估算各個項目的耗時了，但是這樣做是了解其中各項的最好辦法。
3. 軟體工程師的成長
知識要點
個人貢獻者的工作流程，初級工程師的成長方式，TSP要求簡介，三層問題模型與自動化。
3.1 個人能力的衡量與發展
現階段主要就是積累知識、訓練基本能力，其他的太虛了。我也感慨，PSP真的是一個很好的管理工具。
3.2 軟體工程師的職業發展
3.3 技能的反面
怎麼檢測是否真正掌握了某個知識？
- 腦中有一個知識地圖，脈絡非常清晰，用知識的時候就想在地圖上開車，也清楚地知道自己知識的邊界。
-
化繁為簡，能用起來，甚至教會10歲小孩。
書裡面介紹了問題層次的模型。我馬上就想到那個很出名的心理學模型：舒适區、過渡區、恐慌區。我在很多領域都見過類似的東西，這個模型真的很重要。比如說習慣培養的最終目的，就是自動化地做事情。