一、前言
不同於以往的解決問題，這次是需要閱讀，自己思考來提出問題。經過閱讀書上的部分內容，再結合一年半以來的大學經歷，我也清楚地認識到了，它並不是我想象中的那麼單純的以**去實現一切。正如專業的名稱，完成軟體開發就應該像是完成一項「工程」，需要分析設計構建維護等。書中的介紹使我對軟體工程又有新的認識，但是在經過閱讀後所獲得的又一輪新的認知中，又有些許不太清楚，或許也有些不敢苟同的地方。關於個人主觀提出問題，如下。
二、關於問題
第1章 概論：
「軟體工程是把系統的、有序的、可量化的方法應用到軟體開發、運營和維護上的過程。」軟體工程是什麼？不是來自於定義，而是從事軟體開發的經驗拋開概念的自我理解的通俗解釋。「如果一架民用飛機上有乙個功能，使用者使用它的概率是百萬分之一，你還要做這個功能麼？」
個人覺得就好比汽車上的安全帶，我們坐上車就會使用，只是它發揮作用可能是很小的概率。飛機的安全功能使用者幾乎都是在使用的，只是它發揮其作用只有可能是百萬分之一，而且安全功能在我的認知中無論是**都是明令必須的，因此，在例子中感覺稍有些不太合適。
第2章 個人技術和流程：
「單元測試」「效能分析工具」
第16章 it行業的創新：
「迷思之七：成功的團隊更能創新」書中似乎否定了在我以往的認知中乙個成功的團隊應該是更加有創新的活力的觀點。抑制創新的想法是必遭淘汰的，無論何時都是不為時代的變更，社會的進步所容的。乙個成功的團隊也應當是更能創新的，因為乙個在創新方面落後壓抑著創新思想的團隊縱使現在是成功的，那也可能只是一時的成功，將來也必遭淘汰。就比如諾基亞衰落很大一部分原因就是因為設計理念的應循守舊，沒有革命式的創新，而漸漸被其他公司給比下去。更能創新的能力不也正是乙個成功的團隊所必須的嗎？否則，遲早會被其他團隊所比下去，贏在一時應該也不可謂之成功吧。另外，企業是以利益為基準的，這個在書中也有提到，但是是用來否定這個觀點的，個人認為如果從創新帶來的收益來講，如果能夠推廣這份創新，應該更強於缺少創新的情況吧。當然這些也許只是對各種特定詞彙的理解不同和對於實際上目前形勢的不理解才導致的疑問，只是一些個人的看法和不成熟的觀點
。
《構建之法》讀後感 3137102206 吳思婷
構建之法 讀後感 構建之法 這本書，是由縐欣老師所編著，我是在大三下學期學習這本書的。用乙個網路紅語來形容這本書，那就是接地氣。剛接觸到這本書，第一感覺就覺得它與眾不同，不同於以往的程式設計書，它的形式很新穎，排版非常活潑。說實話，可能是因為它每一頁的新穎排版方式讓書本的每一頁看起來文字沒有那麼密密...
構建之法讀後感
書中有提到一句名言 軟體 資料結構 演算法 但是，在真正進行軟體開發時，我們會發現 我們所需要的資料結構和演算法都是現成的，我們只要進行呼叫和實現就可以了。在我學習了本書的第一章後，我認識到了 軟體 程式 軟體工程 從此也可以擴充套件為 軟體企業 軟體 商業模式 軟體從最初的乙個簡單的程式，擴充套件...
《構建之法》讀後感
前段時間，我自學了 構建之法 的1,5,17章，並產生了很多自身的體會。首先，在第一章中我大致了解了我可以在書中學到什麼，如何落實學習。1.1節通過三個簡短的對話，啟發我對什麼是程式，什麼是軟體，什麼是軟體工程，也了解到了乙個軟體不是簡簡單單就能說寫就寫的，還需要考慮各種因素，如人們的需求，功能的可...