第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題的案例，小飛在堅持自己的想法，並說服了同事，但是在開發的過程中他意識到自己方法的缺陷，我覺得這應該是屬於不分主次的情況，因為他想的是完美地代稱目標，而不是先找到一個“足夠好”的方案。我認為在實踐中，要意識到這些思想誤區，當陷入進去的時候，更夠自我提醒或者團隊其他成員的提醒來保證團隊開發的進度。

學習進度條

計劃在本學期讀完。

參考資料

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