《構建之法》，它很通俗的將軟體工程闡述清楚。讀過之後，對於工程有了一定的認識，乙個工程，它與我們現在所學的通過寫**實現一件事情，實現乙個專案是不一樣的，現在所學所做的這些，還遠不及工程這個概念，實現乙個工程，需要完整的team，team中每個成員，軟體工程師需要有一定的個人能力及職業素質等等。而我現在所學的，僅僅是在向著乙個合格的「軟體工程師」發展著，雖然有很多內容看不太懂，但還是總體上軟體工程這個專業、對於自己將來該幹什麼，怎麼做有了大概的了解與方向。
本書第一章主要講了相關的理論和知識點。首先還是那句老生常談的名言「程式=資料結構+演算法」、「軟體=程式+軟體工程」。就像書中所說，我們學過鍊錶、二叉樹等，但是除過特殊要求必須使用鍊錶外，在日常的程式設計寫**的時候從來沒有用過這些鍊錶啊什麼的。再來看書中的例子：一家長因需要出題做了乙個程式，後來老師有了要求需要把這個程式做完整，此時就出現了使用者和需求，進而初步引入了工程的概念。作者還介紹了軟體工程的概念、軟體工程的特殊性等。總之讀過這一章後，對這個專業有了進一步的了解，並且意識到「工程」的概念。
第二章首先講到了單元測試，在此之前從未了解過這個概念。在日常的**編寫過程中，我們會借用別人的**，或者是一起合作，某人負責的某個模組被其他人呼叫，這時候由於對**的不了解，會出現錯誤，那麼單元測試就是乙個很好的解決方案。作者以vsts為例，介紹了單元測試的方法。在剛接觸到「單元測試」這個詞的時候，本以為平常在完成一項任務的時候，在完成某一小功能或者小模組的時候，會舉一兩個例子進行測試，看是否正確，本以為這就是單元測試，但其實這只是單元測試的一塊，或者是類似單元測試。講真的這一塊沒有太讀懂，作者說單元測試必須由最熟悉**的人（程式的作者）來寫，但是我一直以為單元測試只是乙個操作。
第三章寫到軟體工程師的成長，首先是個人能力的衡量與發展，作者用足球隊來做比，足球隊中也存在個**程，也有「陣型」，涉及團隊的配合。軟體團隊和團隊內的工程師也是這樣，軟體中絕大多數的模組是由個人開發或維護的。我認為這章的重點在於成長。作者還指出軟體工程師的幾個思維誤區。分析麻痺：總想著把所有的一切都分析清楚了才開始；不分主次，想解決所有依賴問題：為了完美的完成最初的目標而不分主次；過早優化：陷在乙個區域性問題中一直改進；過早的擴大化。我覺得以前我就處於分析麻痺和過早優化中。作者還以玩魔方為例，通過前人的方法和經驗達到最終的目的不叫精通（通過口訣完成魔方不是精通）。
構建之法讀後感（一）
構建之法是除了大道至簡我讀的第二本有關軟體的書籍。從中都得到了很多上課程式設計的技巧和懂得了各種道理。沒讀這本書之前，以為這本書中都是一些大道理，然而這本書運用生動幽默的語言去打動讀者，作者將自己的感觸和對於軟體工程的理解寫到書本上，更加能夠幫助我們理解這本書和軟體工程。並不太懂軟體工程的概念，只是...
構建之法讀後感
書中有提到一句名言 軟體 資料結構 演算法 但是，在真正進行軟體開發時，我們會發現 我們所需要的資料結構和演算法都是現成的，我們只要進行呼叫和實現就可以了。在我學習了本書的第一章後，我認識到了 軟體 程式 軟體工程 從此也可以擴充套件為 軟體企業 軟體 商業模式 軟體從最初的乙個簡單的程式，擴充套件...
《構建之法》讀後感
前段時間，我自學了 構建之法 的1,5,17章，並產生了很多自身的體會。首先，在第一章中我大致了解了我可以在書中學到什麼，如何落實學習。1.1節通過三個簡短的對話，啟發我對什麼是程式，什麼是軟體，什麼是軟體工程，也了解到了乙個軟體不是簡簡單單就能說寫就寫的，還需要考慮各種因素，如人們的需求，功能的可...