作業要求來自於：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178

第1章 概論

第一章的內容主要說了軟件、程序、軟件工程三者的等式關系以及軟件工程與計算機科學的關系，在此章前半部分我們可以得知“軟件=程序+軟件工程”推導出“ 程序=算法+數據結構”的關系，但在我，看來算法和數據結構固然重要，但是你一直執著於競賽，你是沒辦法做出軟件的。對於大部分人，競賽還是參與為主。後半部分說明計算機科學中的理論研究部分，大多可以從形式上證明，與數學、離散數學、數理邏輯密切相關；計算機科學中與時間相關的部分，都和數據以及其他學科發生關系；軟件工程則和人的行為、現實社會社會的需求息息相關。

在看這一章之前我一直有一個困惑：軟件工程是不是教哪些不怎麽會寫程序的人開發軟件？看完後我才知道軟件工程是教會開發程序的人，更好的，更完善的寫出軟件，而教不會人寫程序。寫程序，需要去練習數據結構和算法。

第2章 個人技術和流程

每一個團隊都需要有特定的流程來管理開發一個項目，每個合格的工程師也都會在軟件生命周期所做的工作中有一個流程，這一章介紹PSP（Personal Software Pro-cess，個人軟件開發流程）。在這章中作者一開始就向我們介紹了“單元測試”，其作用就是：“讓自己負責的模塊功能定義盡量明確，模塊內部的改變不會影響其他模塊，而且模塊的質量能得到穩定的、量化的保證。”什麽是好的單元測試呢？

1.單元測試應該在最基本的功能/參數上驗證程序的正確性。

2.單元測試必須由最熟悉代碼的人（程序的作者）來寫。

3.單元測試過後，機器狀態保持不變。

4.單元測試要快（一個測試的運行時間是幾秒鐘，而不是幾分鐘）。

5.單元測試應該產生可重復、一致的結果。獨立性——單元測試的運行/通過/失敗不依賴於別的測試，可以人為構造數據，以保持單元測試的獨立性。

6.單元測試應該覆蓋所有代碼路徑。

7.單元測試應該集成到自動測試的框架中。How？

8.單元測試必須和產品代碼一起保存和維護。

看完了第二章我有一個疑問就是：每一段代碼都需要單元測試嗎？為什麽如果單元測試的結果是錯的，就一定是程序出了問題？

第3章 軟件工程師的成長

這一節主要講述了初級軟件工程師如何成長？衡量個人工作量和質量的指標、以及在團隊中如何做一個優秀的隊員。

團隊對個人期望是怎樣的？

1、有效的交流
2、按時交付
3、接受團隊賦予的角色並按角色要求工作：是否能接受不同的任務並高質量的完成
4、全力投入到團隊的活動：評審會議、代碼復審等
5、按照團隊流程的要求工作
6、做好準備：在開會討論之前、開始一個新功能、新項目之前，都要做好準備工作。
7、理性的工作:一個成熟的團隊成員必須從事實和數據出發，按照流程，理性的工作。

這一章我的疑惑是在討論質量指標的過程中，提到了是否能夠按時交付。但是實際軟件開發過程中，很多工程師不能夠做到按時交付，那麽工程師不能按時交付的原因到底是什麽呢？他們算不算合格的團隊？

第4章 兩人合作

這一章一開始寫的是如何規範我們寫的代碼，因為如果代碼設計則涉及函數、參數、類等的設計，當你的函數分類明確，參數設置讓人一看就能懂這是用來做什麽的，這樣的代碼就會顯得有層次、有條理。

關於結對編程，其好處是：

（1）在開發層次，結對編程能提供更好的設計質量和代碼質量，兩個人合作解決問題的能力更強。

（2）對開發人員自身來說，結對工作能帶來更多的信心，高質量的產能能帶來更高的滿足感。

（3）在企業管理層次上，結對能更有效地交流，相互學習和傳遞經驗、分享知識，能更好地應對人員流動。

兩個人合作階段包括：萌芽階段、磨合階段、規範階段、創造階段和解體階段。

在每一個階段中，兩個人一起合作，自然會出現不同的意見，沒有絕對正確或錯誤的方法，只有合適或不合適的方法，要學會聆聽別人對自己寫的代碼提出的意見，整合起來，找出更好地方法。

看完了第四章我有一個疑問就是：如果在結對編程的過程中兩個人產生了分歧的話，這不是會拖慢工程進度嗎？為什麽作者還是要推薦結對編程呢？

第5章 團隊和流程

在這一章中作者介紹了軟件團隊的幾種模式：1.一窩蜂模式。2.主治醫生模式。3.明星模式。4.社區模式。5.業余劇團模式。6.秘密團隊。7.特工團隊。8.交響樂團模式。9.爵士樂模式。10.功能團隊模式。11.官僚模式。接下來作者講述了幾種開發流程模式：1.寫了再改模式。2.瀑布模式。3.由瀑布模型的各種變形。4.統一流程。5.老板驅動的流程。6.漸進交付的流程，mvp和mbp。7.tsp的原則。

看完了第五章我有一個疑問就是：當我在開發程序的時候，怎樣在這眾多流程中選擇一個合適我程序的流程模式呢？

《構建之法》1-5章後感