2018-2019-1 20189215 《構建之法》第三章學習總結

第3章 軟件工程師的成長

教材學習內容總結

1. 軟件工程的術語中，單個的成員叫作Individual Contributor(IC)。

2. 軟件開發流程不光指團隊的流程，還包括我的開發流程，由於軟件團隊是由我的組成的，我的在團隊中有獨立的流程

3. IC在團隊中的流程

   • 經過交流、實驗、快速原型等方法，理解問題、需求或任務
   • 提出多種解決辦法並估計工做量（其中包括尋找之前的解決方案，由於有不少工做是重複性的）
   • 與相關角色交流解決問題的提案，決定一個可行的方案
   • 執行，想法變成代碼
   • 合做，測試實現方案，修復BUG
   • 發佈解決方案後，對結果負責

4. 初級軟件工程師的成長

   A. 積累軟件開發知識、技術技能
   B. 積累問題領域的知識、經驗
   C. 對通用的軟件設計思想和軟件工程思想的理解
   D. 提高職業技能
   E. 實際成果

5. PSP認爲的軟件開發的工做量和質量衡量方法

   1.任務 / 項目的大小（代碼行數或者功能點）
   2.花費時間（人數 × 時間）
   3.質量 （bug的數量 / 代碼行數 或者 re-work返工）
   4.是否按時交付（在團隊工做中，穩定、一致的交付時間是衡量一個員工能力的重要方面）

6. 與PSP（我的軟件流程）相對應的是TSP（Team Software Process）團隊軟件流程。TSP對團隊成員的要求：

   交流：和其餘成員有效地交流不管小仍是大的問題
   說到作到（好比按時交付）
   接受團隊賦予的角色並按角色要求工做
   全力投入團隊的工做
   按照團隊流程的要求工做
   準備：開會討論以前、開始一個新功能以前、開始一個新項目以前，都要作好準備工做
   理性地工做

7. 軟件工程師的思想誤區(重點！！！)

   分析麻痹

   一種極端狀況，想要弄清楚全部細節、全部依賴關係以後再動手，分析太多以至於沒法起步前進。

   不分主次，想解決全部依賴問題

   過於積極，想立刻動手修復全部主要和次要的依賴問題，而後就能夠「完美地」達成最初設定的目標，而不是根據現有條件找到一個「足夠好」的方案。

   過早優化

   一個工程師在寫程序的時候，常常容易在某一個局部問題上陷進去，花大量時間對其進行優化，而無視這個模塊對全局的重要性，甚至還不知道這個「全局」是怎樣的。這個毛病就被概括爲「過早的優化是一切罪惡的根源」。

   過早擴大化 / 泛化

   過早地想要擴展軟件的功能、範圍和支持的平臺等。

8. 如何提升技能
   經過不斷的練習，把那些低層次的問題都解決了，變成不用通過大腦的自動操做，而後纔有時間和腦力來解決較高層次的問題。

感覺

本章《軟件工程師的成長》給了我很大的觸動，經過本章我瞭解到了我的在團隊中所發揮的做用、在團隊中的工做、在團隊中也是一個獨立的個體等等。特別是軟件工程師的思想誤區，不少都比較符合我曾經的一些想法，陷入了思想誤區以後，就沒法踏踏實實地先根據當前的條件，找到一個「足夠好」的問題解決方案，再進行改進，這樣就會影響到團隊的開發工做。
關於書本P59第2題的案例，小飛在堅持本身的想法，並說服了同事，可是在開發的過程當中他意識到本身方法的缺陷，我以爲這應該是屬於不分主次的狀況，由於他想的是完美地代稱目標，而不是先找到一個「足夠好」的方案。我認爲在實踐中，要意識到這些思想誤區，當陷入進去的時候，更夠自我提醒或者團隊其餘成員的提醒來保證團隊開發的進度。

學習進度條

	章節數（新增/累積）	博客量（新增/累積）
目標	共17章	共17篇
2018.10.23	1/1	1/1
2018.11.01	1/2	1/2
2018.11.10	1/3	1/3

計劃在本學期讀完。

參考資料

• 《構建之法》（第三版）