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

第一章：概論

這一章運用了很多生動的現實例子來向讀者說明 了軟件工程的定義、組成及其相關特性。

但是也有一些疑惑。例如有一段文字提到“這不是一個缺陷，這是一個功能！”以及下面提到的買車的例子歸咎於“某一類的汽車滿足了他們的需求，他們就會買。如果銷售人員向不適合的目標用戶推銷自己公司的汽車，最好銷售並不理想”。對於這一說法 我反而覺得此處類比得不恰當，首先站在買車的用戶的角度來講，市面上的汽車作為代步工具功能大致都相同，但是價錢卻會有很大的不同，可能是因為車子的材質、品牌效應和功能的性能等等的不同。但是價錢貴的汽車確實會比價錢較便宜的汽車好，相信用戶體驗也會更加好，如果質量好的車子價錢跟質量差的車子價錢相同的話我覺得客戶肯定會選擇質量好的車子，所以作為用戶來說我相信價錢才是影響他們購買選擇的關鍵因素。

在軟件用戶者的角度來說，市面上功能齊全的同一類型的軟件很多，但是受歡迎的程度卻不一樣。同樣是軟件，功能和體驗是用戶看重的，例如同一款拍照軟件，a軟件有拍照美顏的功能，b軟件有拍照美顏及附加特效功能，我相信後者會更受歡迎，我也認為a軟件不會拿出比同類軟件少功能的軟件發售。軟件不是說滿足了現有用戶的暫時需求，用戶就會選擇這款軟件。以我看來，難道軟件也像買車一樣，有了滿足了用戶的需求的軟件，用戶就不會選擇比這款軟件功能更齊全的軟件了嗎？

第二章：個人技術和流程

這一章這一章主要講述單元測試、回歸測試，效能分析及個人軟件開發流程。

本章2.3提到“PSP的目的是記錄工程師如何實現需求的效率，而不是記錄顧客對產品的滿意度。工程師有可能很高效地開發出一個顧客不喜歡的軟件，那麽這位工程師還是一個優秀的工程師麽？

那麽我又有點覺得，相信一個軟件可以滿足大部分用戶，但是不可能滿足所有用戶吧？難道開發出完美的軟件的優秀的工程師才算是優秀嗎？反而我覺得軟件的易於維護，易於修改等等才體現出優秀。

第三章：軟件工程師的成長

本章主要提到評價軟件工程師水平的方法，技能的反面，TSP對個人的要求，軟件工程師的思維誤區。

在3.3節中提到的“專與精的關系” ，例如web開發有的人精通前端有的精通後端，對於創業公司來說，全棧工程師的價值是非常大的，創業公司不可能像大公司一樣，各方面的人才都有。所以需要一個多面手，各種活都能一肩挑。對於創業公司，不可能說DBA前端後端客戶端各種人才全都備齊了，很多工作請人又不飽和，不請人又沒法做，外包又不放心質量，所以全棧工程師是省錢的一妙招。雖然說全棧工程師工資會比一般的工程師會高很多，但綜合下來，成本會低很多，對於個人發展來說全棧工程師更有利於自己的就業 。而讓一個後端和一個前端去溝通，那是不容易溝通的，更不用說設計師與後端了。但如果有一個人懂產品懂設計懂前端懂後端，那溝通的結果顯然不一樣，因為他們講的，彼此都能聽得懂。這讓我想到，如果我是一個很喜歡後端開發的人，那是應該繼續精研後端開發，還是為自己就業而去讓自己成為什麽都懂卻缺乏精度的全棧工程師呢？

第四章：兩人合作

本章主要講代碼規範，極限編程，結對編程，兩人合作的不同階段，影響他人技巧。

本章內容也很貼切我們的專業，因為一直以來我們的大作業都是由兩人及以上的人數完成的，兩人合作中也感觸很深，如果是一個項目分工十分明確的話，大家都各自寫各自的代碼，這樣固然可以，但是常常會出現一些環境版本不同的情況，讓不同的模塊銜接的難度較大。4.5節中提到“結對編程”一對一程序員肩並肩、平等地、互補的進行開發工作，他們並排在一起，面對同一顯示器，使用同一鍵盤、同一個鼠標工作。這個有很現實的問題，例如兩人編程的能力相差巨大呢？倘若一個人立馬打出來的代碼，另一人並不能理解，那接下來的合作還能順利進行嗎？假如立馬講解給不懂的人聽，那又會不會浪費太多時間呢？畢竟還會有更多的代碼需要一起完成。

第五章：團隊和流程

本章主要講述軟件團隊模式和開發流程。

仔細一看，軟件團隊的模式還分很多種，感覺有點模式還是奇奇怪怪的樣子。其中我覺得社區模式真的有點理想，作為為利而生的時代，很多人都不會去做一些付出沒收獲的事情，由於許多專業用戶（主要是程序員）自願地開發它的應用程序，並借助Internet拿出來讓大家一起修改，所以它的周邊的程序越來越多，Linux本身也逐漸發展壯大起來。但是開發和維護Linux操作系統的社區卻是例外，大家有共同的目標以及願意付出自己的努力。對於特工團隊有一點疑問，他們專攻一領域，倘若終有一天他們所擅長的領域杯時代所淘汰了，那麽這個團隊是否就是解散之時呢？

閱讀《構建之法》1-5章感想