在讀《構建之法》之前，我在邏輯思維方面總是有所欠缺，所以導致自己在完成一中演算法時總是慢人一步。

剛開始讀《構建之法》這本書時，書上所提到的很多問題都是我們平常在寫程式碼時候會犯的一些小的錯誤，就我個人而言，在我還沒讀《構建之法》這本書之前，我還不知道我平常在寫程式碼中犯了這麼多的錯誤，雖然這些錯誤都是一些小錯誤，並不影響程式碼的執行，但是看了《構建之法》這本書之後，才忽然明白原來一些小錯誤也會造成大的問題。

第一章中有一個問題，每個人對於不同的事物都有不同的看法，我們的軟體不可能滿足每一個人的要求。但是這句話不是我們逃避問題的原因。我們要儘自己的可能將一切做到最好。在軟體生產前要努力瞭解到人們的需求。基於此進行軟體的開發。軟體開發完成後。不是所有工作都完成了。要繼續對我們軟體進行維護。當我們開始工作時，軟體的維護將是一項大工程，千萬不要小看它！

書本第三章的軟體工程師的成長對我的啟發很大，在學校，我們需要學的知識和語言太多了。往往給我們一種雜而不精的感覺，但是平時在校期間幾乎是沒有多餘的時間去將所學知識學精的。所以平時老師佈置的作業就是很關鍵了，這是我們學習的一個任務。但是，做作業也出現了很多的問題，確實，像書上52頁所描述：我們在平時的作業裡，很多都是通過上網找資料得來的。因為有了上網這個功能，而且大家人手一臺電腦，我們也沒有體會到要去記牢一些最基本的事情。所以此後，我們也養成了習慣，一碰到不會的，馬上百度，卻從來不記住。當下次再遇到同樣的問題時，我們可能還會再一次向百度伸出請求援助之手。此時，我也意識到問題的嚴重性了。某些低階的問題確實不值得我們一而再再而三地百度，這些最基本的東西本就該穩穩地沉澱在腦海裡面，可以不經大腦就自然一氣呵成。否則，你所精通的，其實都是別人的。這也就是《構建之法》對我的一些啟示。

書本第四章的兩人合作和第五章的團隊和流程，我覺的這兩個章節在我們今後進入企業上班工作起很大的作用，做一個程式，不是一個人可以完成的，團隊裡每一個人負責什麼？需求設計誰寫？誰測試？這些都涉及到團隊裡的每一個人，所以團隊中如何分工，如何把各自負責的部分合成一個整體專案，這就考驗了整個團隊的團結分工性。第四章中我發現了以個在平常的程式設計裡我的錯誤，在我的程式中，我的註釋大多都是在變數名的後面，標註了該變數是什麼。突然覺得這樣的做法很蠢，一個變數，其實要是命名做的好，那麼讓人一目瞭然，就少了一些沒必要的註釋。

這本書告訴了我們詳細的教學計劃，和教學目的目標和手段。讓我們自己考慮什麼事健康的師生關係。然後給我們簡單得講述了軟體工程是什麼，用通俗易懂得語言並類比其它學科簡單介紹軟體工程行業的發展。

　這本書對我的啟發很多，無論是做管理還是做技術，人總是有學習的能力，相信有這個能力，不用糾結要做管理還是做技術。