構建之法閱讀筆記01

  最近閱讀了鄒欣老師寫的《構建之法》這本書，看了前幾節以後，我發現王老師如今的教學方法就是按照書中所講，在作中學，感受這樣學習確實頗有效果，少了不少的枯燥乏味的串講，上課也比較有趣味性。

  開篇第一章概論，第一節中用程序員所熟知的：程序=數據結構+算法的名言，來引出程序員安身立命的程序。用程序員阿超給兒子設計出題程序，以後又根據學校的不一樣需求，將項目不斷擴大，進而從一個簡單程序，到應用軟件，最後到軟件服務。最後獲得一個推論：軟件=程序+軟件工程，一個擴展推論：軟件企業+軟件+商業模式。獲得結論：程序（算法，數據結構）是基本功，可是在算法和數據結構之上，軟件工程決定了軟件的質量；商業模式決定了一個軟件企業的成敗。軟件從業人員和軟件企業的道德操守會極大地影響軟件用戶的利益。接着經過類比玩具階段、業餘愛好階段、探索階段、成熟的產業階段的幾個小故事，告訴咱們軟件的開發也是從簡單到複雜的，並列出了在每個階段成功或者失敗的影響。

  單元測試、迴歸測試、效能分析，軟件的測試是衡量軟件是否合格的標準，做者提出，單元測試應該在最基本的功能/參數上驗證程序的正確性，必須由最熟悉代碼的人來寫，單元測試事後機器狀態保持不變，單元測試要快，產生可重複、一致的結果，獨立性，覆蓋全部代碼路徑。

  第三章做者講述了團隊對我的的指望。

（1）有效的和其餘隊員交流
（2）說到作到，按時交付
（3）接受團隊賦予的角色並按角色要求工做
（4）全力投入團隊的活動
（5）按照團隊流程的要求工做
（6）作好準備工做
（7）理性的工做

不少人認爲本身須要靈感和激情，才能爲宏大的目標奮鬥，才能成爲專業人士，著名的藝術家Chuck Close說：我總以爲靈感是屬於業餘愛好者的。咱們職業人士只是天天持續工做。今天你繼續昨天的工做，明天你繼續今天的工做，最終你會有所成就。

  做者又提出了軟件工程師思惟的幾個誤區：

（1）分析麻痹
（2）不分主次，想解決全部依賴問題
（3）過早優化
（4）過早擴大化/泛化（Premature Generalization）（畫扇畫，調侃目標和遠景）

  經過對這一部分的閱讀，我發現上面的問題在我平時的學習中也存在，正若是凍維修木桶同樣，分析太多，出現麻痹，而遲遲不敢動手，致使在大的項目面前很難取得成效，另外一種像小飛同樣，爲了解決一些無關的問題，而偏離了本身的方向，進而卻是項目難以進展。

  從此的代碼學習中，我要合理的分析問題，不能像以前同樣，過於畏懼大的項目，致使無從下手，也不能爲了整個大項目的冰山一角，而拖慢了總體的進度，要合理的進行規劃，不能使本身陷入思想誤區。