《構建之法》閱讀筆記（1）

《構建之法》To Teacher & TA和第一章閱讀筆記

大馬哈魚洄游模型

軟件工程按照經典的瀑布模型 
1. 需求分析 
2. 設計階段 
3. 實現階段 
4. 穩定階段 
5. 發佈階段 
6. 維護階段

事實上在現實世界中，軟件工程師的職業發展與瀑布流程恰好相反

1. 畢業進入公司（或者實習生），開始學習並維護一些已有的軟件（維護階段），主要由本身的師傅（Mentor）帶領
2. 可以在項目中改一些 Bug，而後發現發佈小規模的更新版本（穩定/發佈階段），聯繫重構，開始和其餘同事打交道
3. 有機會負責重寫一個較小的模塊，沒有多少文檔，本身要寫不少代碼（實現階段）
4. 表現好的員工，有機會設計比較大的模塊，本身寫一些文檔（設計階段），和更多成員發生工做聯繫。在一些狀況下還能發揮領導做用
5. 員工逐漸成長爲團隊的骨幹，有機會計劃新的項目（需求分析）

---

現實生活中，學習的過程 Alpha 階段

1. 開始維護之前的同窗開發出來的程序，理解程序，理解用戶的痛點
2. 找 Bug，改 Bug，重構小部分代碼；一部分同窗能夠開發測試用例
3. 在現有版本的基礎上作少部分增量開發，快速分佈並收集用戶反饋

---

Beta 階段

1. 根據 Alpha 版本的反饋，進一步分析需求，估計實現需求的難度（此時應該能理解客戶需求是什麼）
2. 設計 -> 開發（重構）
3. 迴歸測試（用到上面開發的測試用例）
4. 發佈，收集用戶反饋，看看新的版本是否真的解決了用戶的問題

因此這種學習模式就像從瀑布下方一步一步上溯到源頭，而後又從源頭流下去，故稱之爲「大馬哈魚洄游模型」

 

閱讀第一章我有以下體會：

1.我過去學習編程語言時，完成做業的時候看了題目就動手編寫，不會就百度，再不行就找同窗copy。而身邊同窗要不和我同樣,要不靠大神，編程得永遠就那麼幾我的，你們的做業都就幾個版本而已。過去上課，老師嚴一些就聽，而大多數課都在走神、聊天、玩手機。過去編程不注重流程及測試。 

2.很顯然過去的作法是不對的，上課應該認真聽講，過去那樣學不到知識也荒廢了時間。看過本書及上過軟件工程課後，我知道了編程像解決數學大題同樣，要把大問題化小問題，運用「拆分」的思想，編程就容易許多了。身爲信息類專業，應該讓編程成爲咱們的一種習慣。編程時遵照PSP，能夠更規範，程序錯誤更少。

3.在老師的帶領下，培養學生編程的習慣；老師能夠把編程的思想方法教給學生。學生應多閱讀編程書籍，天天寫幾行代碼。爭取天天都要擠出兩個鐘頭來進行編程。

 

過了好長時間才展開閱讀，時間有點緊，之後天天都會看一點，閱讀這本書真的使我受益不淺！

To Teacher & TA