由於放了國慶假所有看書的效率不是很快，只能慢慢的去研讀研讀，不過正是這研讀才能使我有了深刻的體會。

第一章：概論

第一章主要內容是講述了計算機科學的領域，軟件工程和計算機科學的關系，軟件的特性，軟件工程的定義與組成部分。

之前很多老師問過我們：“什麽是軟件？”，我總是想到了軟件=數據結構+算法，但是看了這一章之後，我突然醒悟原來我之前的角度和看法都是有誤的，正確的思路是程序就是數據結構+算法、軟件即程序+軟件工程、軟件企業即軟件+商業模式。程序包括算法、數據結構是基本功，但是在算法和數據結構之上，軟件工程決定了軟件的質量，商業模式決定了一個軟件企業的成敗。將我從軟件就是單純的一串串的代碼的死胡同中拉了出來，帶我進入一個新的視野。

在1.24中，有句一著名的笑話：這不是缺陷，這是一個功能（It’s not a bug，it’s a feature）！很多人認為有Bug就是質量不合格，沒有Bug就是質量完美，其實這也未必。我們大街上看到很多不同品牌的汽車；這些汽車出廠時都通過了各自的質量檢測，符合行業的質量標準。但是你問路人哪些車的“質量好”，很多人會告訴你有些車的質量大大好於另外一些車，那為什麽還有人買那些質量“不夠好”的汽車呢？對於某些顧客來說，某一類的汽車滿足了他們的需求，他們就會買。如果銷售人員不經市場調研向不合適的目標用戶推銷自己公司的汽車，最後銷量未必理想。其實是否存在一個問題只是看你的角度問題，站在一個角度看可能是一個缺陷但是站在另一個的角度上看，可能就是一個完美的東西。例如在沙漠上看黃金會遠遠不值於水，但是在城市裏看水的價值將會遠遠的不夠黃金重要。

第二章：個人技術和流程

第二章主要內容是講述了單元測試，回歸測試，效能分析和通過PSP講解個人軟件開發流程。

在2.4，上有一句話“哎，你看我一通加班，就寫好了程序，得了高分。也不用啥軟件設計的原則，事先也不用需求說明書，也不留什麽文檔，就搞定了！軟件容易得很！“。這句話就是學生陷入了”我有銀彈“得誤區，雖然短期看來完成了作業，也得到了鍛煉，而且花費的時間很少!但是細細分析，長期來看是對自己不利的，首先，這樣在學習期間並沒有學習到很多東西，只是單純完成作業而已，其次，打代碼的習慣並沒有很好的得到練習，缺少了設計原則，以後工作會處於一個非常不利的地位。

我覺得，個人學習應該一步步慢慢來，穩紮穩紮的向前走，而不是為了應付而應付。

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

這章的主要是評論軟件工程師水平的主要方式，技能的反面，TSP對個人的要求，軟件工程師的思維誤區。

在3.3中，有五個等級分別是臨時的寄托或工作、工作、職業、投身的事業以及理想的呼喚。我覺得前三種的進步空間是很小的，後面兩種可以讓你有很大的進步空間。我在一篇博客中看到一句話：“要麽不要做，要麽就精於事情。”只有你投身於事業中，你才能感到樂趣，才能夠真正的完成一件事情，我覺得一個軟件工程師的成長就是要以投身事業的態度去學習

第四章：兩人合作

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

在4.5.2節中，我看了這一段文字“在結對編程中，因為有隨時的復審和交流，程序各方面的質量取決於一對程序員中各方面水平比較高的那一位。這樣，程序中的錯誤就會少得多，程序的初始質量會高很多，這樣會省下很多以後修改、測試的時間”。雖然我覺得這樣會帶動那個水平比較低的人，但是我覺得還是讓兩個水平差不多的人結對比較好，可以讓這個程序的會更加的完美，只有融合了不同思路的軟件才能夠更全面，使這一個軟件不至於那麽的片面，我看過很多人做作業都是抱大腿然後都是由那個大腿一人決定了這個作業的好壞，但是這樣的成品並不是很好。

第五章：團隊和流程

這章的主要內容是典型的軟件團隊模式和開發流程都有哪些？各有什麽優缺點，TSP,MVP,MBP,RUP。

在5.1中，有句話：“這七八個人是團隊（Team）麽？不是，他們只是一群烏合之眾，臨時聚集在一起，各自完成任務就領錢走人。我永遠相信著一句話：”一加一大於二“。一個團隊的效率肯定要大於個人的能力，但是一個完美的團隊肯定是一個強大的軍隊。我覺得想要成功就應該組一個團隊，而不是找一群烏合之眾去完成一個項目。然後在一個團隊中要有明確的分工，不應該個人在一個集體中不知道自己的定位是什麽。

總結：雖然我現在是一個還沒入門的軟件工程師，但是看了這些內容後，我照著著思路走下去，我會漸漸的會越來越優秀。

作業三：讀《構建之法》1-5章讀後感