讀小學的時候，老師就告訴我們，每讀一篇文章或者一本書都要有自己的感想，要有自己的想法。在這個光怪陸離的社會中，我們總是沉浸於高速的網路資訊中，我們總是驚訝於每時每刻的新鮮事物，卻忘了最原始的、最正宗的課本。 高爾基曾說：“書是人類進步的階梯。”。能夠在自己有限的時間裡學到儘可能多的知識是好事，我們總是抱怨課本上的知識是有限的，企圖從其他渠道來獲得更多，卻往往忘記了最根本的東西。似乎有點偏題了，但我在讀書的過程中真的感悟了很多，紙質版的書沒有電子版的書攜帶方便跟環保，但每次看到它的時候總能提醒我看它，它就像一個朋友，每晚在熄燈後還能陪我一起學習。
讀第一章的時候，我最先學到的，就是不斷地根據需求分析去完善自己的程式。還記得那個時候老師讓我們自己註冊一個屬於自己的部落格，然後讓我們寫一個能夠自動生成四則運算的程式。在第一章的1.1.1中，阿超不斷地根據“客戶”的要求的要求完善自己的程式，我們可以看出，每一個軟體服務都是由一個個應用軟體擴充套件而來的，而每一個應用軟體都是由一個個簡單的小程式組合而成，每一個小程式的根本，就是一行行熟悉的程式碼。那麼，問題來了，既然我們要不斷地根據客戶的需求來編寫程式，那我們平時寫的程式碼在今後如若遇到不同需求的時候幾變成了一些廢棄的資料，不能再重複使用了嗎？那麼程式碼的意義又將失去了，我們創造了它卻又拋棄了它，正如拋棄了自己的孩子一般，創造它又有何意義啊？
想到這裡，我翻開了第二章。第二章講的是個人技術和流程，最吸引我的一句話是：“你的RP是由你的程式質量決定的。”這讓我發現好的單元測試才能準確、快速地保證程式基本模組的正確性。好的程式總是要在最低的功能上驗證程式的正確性，正如很多軟體他們的原始碼是在最低的版本上編寫的，便是為了能夠在任意版本上相容。雖然在功能上可能會比較不方便，但很多地解決了相容問題，畢竟現在科技高速發展，人們總不能預計資訊發展的速率，因此，在最低的功能上驗證程式的正確性是最明智的決定。此外，好的單元測試必須由程式碼作者來寫，這樣才能夠保證程式在測試的過程中有相對性。轉而到迴歸測試，我們在驗證心的程式碼的時候改正了自身的缺陷，同時也需要驗證新的程式碼有沒有破壞模組的現有功能。在修復bug的同時，也應當要注意做容錯處理，這樣才能做出一個好的程式。對於第二章，我沒有針對於哪一節的問題，只是覺得整體都是在講一些很理論很實際的東西，作者用不同的視角來演繹不同的人物性格，告訴我們個人技術和流程應該注意哪些細節，只有不斷測試，不斷完善，才能做出更好的軟體。
之於第三章，我覺得讓我感受到的更多的就是要堅持。寫程式碼與唱歌跳舞寫作一般，都是一門藝術，都是一門讓我們一輩子都可以為之感興趣的藝術。我在寫程式碼的時候，我總是喜歡根據以前自己在學java或者c的時候積累下來的一些小程式，然後根據自己想實現的功能加以改進，修改成自己想要的那一系列的程式原始碼。在我眼裡 ，程式都是一樣的，都是通用的，沒有好程式與壞程式之分。在每一個程式設計師精心編輯下，每一段程式程式碼都有它獨特的意義。可以說，程式設計的過程本身就是一門藝術。在3.3中，筆者談到一個人從五年級到成長後的魔方“技能”的變化，這個例子告訴我們，沒有成熟的技術，往往會達不到需求分析，但在3.2中，我們可以看出，一個程式所需要的技能並沒有多少，我們何必要浪費那麼多的時間去讀計算機專業，直接去參加Java程式設計培訓班不是更快，學費與學時都會相應減少，效率說不定還會加倍。所以我覺得，這是一個嚴肅而又認真的問題，它讓我思考為什麼要讀大學。
轉而到第四章。還記得那個時候助教先生給我們出了一個結對程式設計的題目，讓我們跟我們的小夥伴一起結對編寫一個帶介面的四則運算程式。書上有一句話我記得特別清楚：“沒有'我的程式碼'、'你的程式碼'或‘他/她的程式碼'，只有'我們的程式碼'。”結對程式設計，讓我們變得更加團結。在編寫程式的時候，是沒有導航員與駕駛員之分的，每個人都可以提出自己的想法，只為能夠完成更好的程式碼。我們在學習正確的給予反饋的過程中，也收穫到了最真誠的資訊，朋友，總是在最困難的時候出現在你身邊幫助你的人。在這一章中我學會到的是如何跟隊友合作，在分歧中更快地達到共識，把我們各自的長處集中在一起然後改進其他缺點跟不足。有人說：“選隊友是至關重要的。”那我們在選擇隊友的時候應當要怎麼考慮呢？強強聯合？還是以優帶弱？是否可以詳細解說一下應當如何選擇自己的隊友？
第五章依舊是講關於“團結”的內容，只是由兩個人擴充套件到一個團隊。看完這一章，我得出的結論是：團隊跟個人的關係——團隊是由個人組成的，個人離不開團隊，團隊又依賴於個人，個人與團隊是相互依存的兩個實體。每個人都有每個人的優點，取每個人的長處，改進每個人的短處，這樣就可以更快地做出更好的程式了。想到這裡，我的嘴角不禁微微一翹，我的隊友總是那麼的給力，我們之間沒有水平上的差異之分，只有越來越勤奮，然後在不斷地磨合中一點點的進步。在5.3的開發流程中，我注意到了瀑布模型，這是最原始的程式設計模式，在最初就確定好需求分析後對於以後的程式設計就會有一個明確的目標。但是時代在變，資訊在變，我們的需求也在變，這個時候我們就由最初的瀑布模型變形發展成了圓形模型，在這個模型中我們可以隨時根據客戶的要求更改需求分析，並編寫出更符合時代需求的程式。但在這裡，我有一個疑問，瀑布模型跟圓形模型都有它的特點——瀑布模型需求明確但不實用，圓形模型實用但需求分析不明——我們應當怎樣選擇不同的開發流程才能開發出適應時代的軟體呢？
讀完了《現代軟體工程——構建之法》的第1~5章後，我有許多感想，笨拙的文筆總是不能很好的詮釋內心的想法（請原諒我是理科生），但願在接下來的時間裡，能夠在良師益友的支援下學習到更多的知識，開發出更好的軟體，做一個合格的程式設計師。Everybody，come on！