1：為何讀「構建之法」
抽出時間，看看軟體工程這本書，就像老師說的「好書不讀就浪費了，怎麼也49
塊」。不讀還對不起我們的毛爺爺呢！剛剛拿到這本書的時候，「構建之法」映入眼簾，心裡在想這本書是在教我們怎樣去「建造」好乙個軟體嗎？怎麼這樣取名啊？一開始我只是任務式的看完一到第五章，只是單純的看並沒有太大的思考。不得不說，相對於別的書籍，這本是那樣的枯燥乏味，沒有一點點的吸引力，一眼看去，全都是理論知識，沒有實際的相關操作。要用心看下去是挺難的，因而對於每一章我都是一眼帶過，想的只是怎麼快點看完，並沒有想其他的。這是我第一次閱讀這本書的想法和結論。
但當我讀第二遍的時候，我就不然而然的換了種思想，為什麼老師要我們看書，恐怕不是只為了不浪費錢，更多的是讓我們接觸了解軟體工程究竟為何物。於是心中就產生了一些疑問「什麼是軟體工程，為什麼我們要乙個學期去學習」。帶著這些疑問，我重新閱讀了一遍「構建之法」，用四個字可以概括「受益匪淺」。
2：看完書後的第一感覺
看完一到第五章後，就自然而然的把一到第五章串成這樣的一條線：什麼是軟體工程，個人在寫**的時候怎樣做才能寫出高效有用的**。以後作為軟體工程師又應該怎樣的不斷進步，怎麼在團隊中找到適合自己的位置。對於一到五章，這樣串線不知道對不對（第乙個問題）。
3：疑問解決，心生愉悅。重生疑問，如何作答。
看完第一章，恍然大悟，原來這就是軟體工程啊。一直以來，我以為軟體工程就是和建築物的構成是一樣的，只是系統的、機械的把所有的**有規律的集合在一起，從而構成乙個軟體。看完定義才知道，軟體工程是「把系統化、規範化、可度量的途徑應用於軟體開發、執行和維護過程」。軟體可以成為商品，但又不同於別的商品，它是乙個邏輯產品，具有抽象性和易複製性，由程式和軟體工程組成。軟體也會像樓房一樣慢慢出現裂痕，這時候就需要維護保證其可用性和耐用性。這時候程式設計師就要重新檢測自己的****出現錯誤，怎樣維護才可以補救。與其出現問題後才補救，不如將問題扼殺在搖籃之中，這時候的就出現了「單元測試」。單元測試可以有效地保證模組的質量。諸如此類的還有效能分析測試，就是
說對於同乙個功能，在保證功能不受損的前提下，怎樣的**才能節約系統開銷。例如33
頁中的for
（）迴圈條件，只是將
i改為i，
system.collections.arraylist_get_count()
的呼叫次數和時間都大幅度的減少，關於這一點我一直都想不明白，只是換個條件為什麼差別就會這麼大，這是什麼原因導致的，以後我們寫程式的時候怎樣避免這種現象的產生。（第二個問題）
4：「團結就是力量」，善於運用團隊，發現無限潛能。
第二次作業的時候，當老師提出結對子的時候，我就覺得只是這麼乙個小小的程式，沒有結對子的必要性吧。剛開始結對子的時候是帶著一點點牴觸心情進行的，可越到後來越發現結對子的好處。尤其是看完書後覺得，結對子不是單純的從乙個人變成2
個人寫。而是從乙個角色變成另外乙個角色，就像是領航員與駕駛員，在不同的位置完成不同的任務，但目的都是一樣的。」**複審「是乙個比較難理解的名詞，是說重新把**從頭看一遍，然後再找出錯誤嗎？如果是這樣，那為什麼不叫做」**重檢「呢？書中詳細的介紹了**複審定義，**複審步驟及意義，但我依然無法明白「**複審」究竟是什麼意思。為什麼只要求在「**規範」的前提下檢測**呢？（第四個問題）
俗語有說「你有乙個蘋果，我有乙個蘋果，2
個人在一起就會有
2個蘋果」，思想也是如此，但思想不應該只是簡單地相加，應該進行系統的匯合，成為「思想結晶」。軟體的產生需要的是乙個團隊，乙個人是可以寫**，但寫出來的都是一些功能相對簡單，含有較多
bug的**，但是團隊不僅可以避免這種情況，團隊不僅有一致的目標，而且分工明確，互相依賴合作共同完成任務，這樣可以大大提高軟體的生產時間和軟體利用率，這也是為什麼要有團隊的原因。第五章
84頁開始介紹了幾種軟體團隊模式，看起來每一種都有自己的優勢。對於沒有團隊合作經驗的我來說，應該怎麼去選擇合理有效的模式呢？ （第五個問題） 。是根據具體情況？還是聽從團隊成員的想法決定模式。我想應該都不是這樣吧。
5：啟發人生思考，未來怎麼走，現在應該怎麼做，做什麼。
未來是怎樣的，誰也沒有辦法預料。所以我們應該把握當前，為自己努力。「軟體工程師的成長」讓我更好的了解了未來的路應該如何走。我報考了2023年5
月份的軟考程式設計師，想一步一步的努力，最後得到軟體工程師這個證書。有時候會想，我只是很簡單的學習了軟體，只是會編寫很簡單的**，而且我們是
2b學校，以後出去找工作真的能找到乙份好的工作嗎？儘管第三章講解了如何成為一名「軟體工程師」，如何檢測自己是否為合格的工程師。書中的第
45頁詳細的介紹了「初級工程師的成長」，我也在反思自己有沒有做到書上的其中一點，怎麼才能做到。想了很久也沒有想明白。我到底一樣怎麼做才能成為一名初級軟體工程師（第三個問題）。是從軟考最底層的程式設計師過度到初級的軟體分析師，最後再考軟體工程師。還是說我按照書本的45
頁的關於初級工程師的介紹，積累了相關知識等，最後才去軟考「軟體工程師」。
6：總結
看完此書最大的收穫就是知道一名合格的軟體工程師是怎麼樣的，要怎麼做才能進步。書可以讀很多次，每一次都會有不同的感受，對事物都會有不同的認識。我想這可能就是成長的一種表現吧，隨著成長我們隊許多事情就會用不同的角度思考。對於「構建之法」，我也是這樣認為的，現在我只是很粗淺的認識了軟體工程，談不上任何實際，但乙個學期的量變可以讓我看到質變，到那時候再細細讀，可能就是更加有感受，更加知道怎麼做才能學到自己想要的吧。
加油吧，少年！精彩的人生正等著我們每乙個人呢！
讀《構建之法》的第一次隨筆
在收到紙質書籍到手之前，我簡單的看了一些多看閱讀上的試讀章節。第一章開始便以程式猿們程式設計遇到的各種問題引出了軟體工程的重要性。在乙個工程的進展過程中，各種的不確定性因素會以多種不同的方式阻礙專案的正常運轉，例如，軟體的質量提公升，特殊需求的引入，文件 流程和工具的正確性等都會蠶食專案的工期和質量...
我會用我獨特的愛去愛你一輩子，直到天荒地老
喜歡簡單的事物乾淨的東西清楚的感覺.人生本來非常簡單，而且簡單就是完美 因為不夠好所以你們離開我也不能抱怨 你雙腳盡濕行之所及依舊有光 只不過是愛自由,害怕任何一種關係都會束縛自己 愛乙個人就要拉屎給他吃 我願用愛為你加冕還你一世為王的安眠 我想不再那麼心軟可還是做不到 有些故事，只知道開頭和結尾就...
第一周 關於讀《構建之法》的一點微小的感想
計算機書目琳琅，並且大多數很厚，如果沒人引導，盲目的找書看的話，除了給個人的心理乃至生理造成壓力外，往往浪費了時間，收穫甚少。我知道 構建之法 這本書，是在楊貴福老師的軟體工程的課上。老師說，鄒欣這個人很厲害，他寫的 構建之法 這本書很好。事後我看了一下亞馬遜和豆瓣上的評分，確實還不錯，亞馬遜有五顆...