當我準備來看這本書的時候，我並沒有著急的就去翻文章的內容。因為我平常看書的習慣，所以我首先先看了一遍《構建之法》這本書的目錄、序言甚至讀者反饋。在認真的閱讀了一番之後，我覺得書中序言的第一版讀者反饋是我看完整本書後比較欣賞的乙個亮點。我在看這本書之前從未發現書中會有讀者反饋，而這一小小的細節也說明了作者確實是用心在寫這本書，側面體現了作者對讀者的意見是非常看重的，也就是這麼乙個小細節瞬間點燃了對這本書的興趣，下面內容就是看完本文後的一些感悟。
我在看的時候遇到下面幾個問題了：
書中許有部分英文並沒有註解，對英文比較差的讀者來說，英文的未標識對閱讀還是會造成了比較大的影響，雖然使用google可能加深印象，但是就這本書來說作者更想表達的是一種思想，而使用群體大多是新手，因此沒有註解的專業術語可能會讓讀者更加迷茫。比如第一章的1.2.3。
書中用到了偽**，可能是由於對單元測試的不熟悉不夠理解，看到書中第二章單元測試的**，由於習慣性看到**都想去驗證一番，正準備驗證**的可行性，結果嘗試了一半的時候發現這其實只是程式的乙個思想，並不是完整**，這是由於沒有認真閱讀造成了錯誤的理解。
文中大部分重點放在了測試上面，交替寫到了管理、團隊合作、使用者體驗等等，但是看到最後，我始終沒能理解作者表達的主線。作者通過單人到團隊，再到管理和使用者，並在其中穿插著許多專案例項。但是由於我專案經驗的缺少和對企業的不了解，許多具體的專案問題也只是走馬觀花，並沒有很深的體會。比如第二章第40頁的回歸測試、第五章第97頁的瀑布模型的變形、第五章的5.3.6、第十三章的13.2.4等等，都是需要積累的經驗，可能對於豐富經驗的程式設計師來說這些都是很簡單的基礎，但是我只是新手，對這些有的不太理解。
文中覆蓋面太廣，可能整本書作為新手的我們整體看下來只能讀懂其中的一部分，收穫很多但是疑問和難懂的也很多。如果我們只是在技術方向發展，後面的專案經理以及管理經驗可能就顯得不那麼重要了。
還有一點，這本書在每個章節的最後都乙個模組——練習與討論。我覺得這個模組設計的很好，對我們特別的有用。給我們問題讓我們思考，讓我們去和別人討論溝通是很好的。而且還提供了很多有趣有用的博文和各種**。
《構建之法》這本書讓我覺得寫這本書的作者一定是個飽經風霜、經驗十分豐富的程式設計師，也是乙個對於美有苛刻追求的文藝學者。書中無時無刻都充滿著文藝氣息。巧妙地將文藝和枯燥的程式設計完美的融合在一起，並結合經驗用很通俗的文字表達出來。書中**並茂，而且都十分的有趣又有新意，不是一本無趣枯燥的普通的教學用書。書中有舉了很多的例子，還有用很多的外號代號，還有一些新聞、生活中的事例都通過鄒欣老師和我們的軟體工程聯絡在了一起。比如第八章的老人家環遊中國騎行的例子；第十章的剪頭髮的例子。都可以看出鄒欣老師是很用心的出了這本書。
構建之法讀後感
書中有提到一句名言 軟體 資料結構 演算法 但是，在真正進行軟體開發時，我們會發現 我們所需要的資料結構和演算法都是現成的，我們只要進行呼叫和實現就可以了。在我學習了本書的第一章後，我認識到了 軟體 程式 軟體工程 從此也可以擴充套件為 軟體企業 軟體 商業模式 軟體從最初的乙個簡單的程式，擴充套件...
《構建之法》讀後感
前段時間，我自學了 構建之法 的1,5,17章，並產生了很多自身的體會。首先，在第一章中我大致了解了我可以在書中學到什麼，如何落實學習。1.1節通過三個簡短的對話，啟發我對什麼是程式，什麼是軟體，什麼是軟體工程，也了解到了乙個軟體不是簡簡單單就能說寫就寫的，還需要考慮各種因素，如人們的需求，功能的可...
構建之法讀後感
第一章 軟體工程。寫軟體就是碼 寫出來，組合語句和演算法，實現需要的功能。但是軟體的開發需要一定步驟，有團隊合作精神，經過需求分析明白客戶需求，要什麼功能，並完成軟體的概要設計，再進行討論並與客戶溝通。然後進行軟體設計，然後程式 編寫，軟體測試debug，體驗版，後續維護等等。這樣才是乙個專案。軟體...