拜讀完《構建之法》第一至五章，我了解了軟件工程的重要性，它就像是一棟房屋的建設，是一項大工程，必須有工具，有能力，有計划才有可能實現這么一個工程。對於那些生硬的概念，書中舉了形象生動的例子，很多都能讓我們聯想到自己日常生活，能很好的記憶和理解其中的奧妙。
第一章：概論
1) 在讀此書之前，我一直以為當一個團隊確定了負責一個項目之后，他們的成員不會再有所修改，會對所負責的項目負責到底。但實際上，軟件團隊是會流動的。為什么要有人員的流動呢？是出現了現有團隊解決不了的技術困難，需要新技術新知識的支持，還是現有團隊身擔多職，需要人手幫忙？另外，不止是軟件程序會有bug，團隊也會有bug。處理好bug是創造“足夠好”的軟件的基礎，但在校園學習過程中，我們常常會忽視bug，甚至把它留在最后處理。
2) 用戶體驗，很多時候我們會在軟件商店下載各種功能相似的應用，比如，我們曾經下載過無數個背英語單詞的app,而能留到最后的只有“百詞斬”。軟件的用戶體驗的好壞就在於他是否與同類型的軟件比起來更好用。用戶體驗對一款軟件的考驗很大，市場上也有許多新開發的軟件，這些軟件有的一夜之間下載量飆升，有的卻不了了之，也有的在一段時間內飆升后再被淘汰。比如像素鳥，前段時間很風靡，現在也逐漸退去光環。我覺得這也和用戶體驗有密切相關的關系，作為一款游戲，前一段時間因為游戲有難度而風靡，而后來聽說有些大神通了關，但我相信大部分人都是沒過幾根柱子就game over了的。這樣沒有獎勵又屢戰屢敗的游戲，用戶大概也不太想要堅持玩下去。但游戲的有創意又容易上手，就是太容易game over。
3) ＡＰＩ到底是什么，和ｊａｖａ的ＡＰＩ一個意思嗎？
百度百科解析：API（Application Programming Interface,應用程序編程接口）是一些預先定義的函數，目的是提供應用程序與開發人員基於某軟件或硬件得以訪問一組例程的能力，而又無需訪問源碼，或理解內部工作機制的細節。
4) “沒有銀彈”論斷？
互動百科：沒有銀彈--是Fred Brooks在1987年所發表的一篇關於軟件工程的經典論文。該論述中強調真正的銀彈並不存在，而所謂的銀彈則是指沒有任何一項技術或方法可以能讓軟件工程的生產力在十年內提高十倍。
5) 書上提到了三種學院，講解了計算機科學和軟件工程的區別及其互助性，那軟件學院和軟件工程學院所學的是否有區別呢。
第二章：個人技術和流程
1) 個人編寫模塊時要有單元測試，畢竟最后的軟件是由多人合作完成的。我們要確保我們所寫的模塊能被他人調用，並且代碼清晰易懂，不影響其他模塊。用vsts寫單元測試我們沒有接觸過，看着書也印象不太深，它是否能測試所有的計算機語言呢。希望有時間實踐操作一下。另外，對於單元測試自動化，什么是單元自動化，要怎么做呢。百度了也很暈。以及GitHub之前覺得它的圖標很可愛，有去了解過，但是沒看懂它能干嘛。
2) 原來使用for循環調用a.lenght;這些調用的獲取數組長度的方法會增大時間復雜度。
第三章：軟件工程師的成長
1) 對於一個軟件工程師，個人能力尤為重要，如果能力不足，那么做什么都無從下手，甚至還會有負面影響。我一直以來都覺得現在所學的專業，出去工作頂多是個程序員，或者至少也要干幾年才能是工程師，但看了課本，我覺得我們似乎可以成為一個初、中級的軟件工程師。程序員與軟件工程師之間有很大的區別，有人說，這種關系就像是民工和包工頭的關系。程序員被指揮，工程師當指揮。也有人說只是名字好聽點而已。我覺得，程序員主要就是負責成天按照上級發的任務編程，軟件工程師呢，在一個項目里會有大量的建模、構思和設計。
2) 在學校，我們需要學的知識，語言太多了。往往給我們一種雜而不精的感覺，但是平時在校期間幾乎是沒有多余的時間去將所學知識學精的。這個時候，我們該怎么辦？坐等畢業之后就職公司給我們培訓嗎？我覺得，參加比賽是對付學而不精的好方法，比賽會讓你控制好你的每分每秒，也可以以比賽的形式逼着自己去學一些東西，若是得了獎，可以豐富簡歷，若是沒得獎，那我們也從中學到了很多。重在參與。
3) 確實，像書上52頁所描述。我們在平時的作業里，很多都是通過上網找資料得來的。因為有上網這個“好東西”，我們也沒有體會到要去記牢一些最基本的事情。所以此后，我們也養成了習慣，一碰到不會的，馬上百度，卻從來不記住。當下次再遇到同樣的問題時，我們可能還會再一次向百度伸出請求援助之手。此時，我也意識到問題的嚴重性了。某些低級的問題確實不值得我們一而再再而三地百度，這些最基本的東西本就該穩穩地沉淀在腦海里面，可以不經大腦就自然一氣呵成。否則，你所精通的，其實都是別人的。
第四章：兩人合作
1）在合作里面，代碼風格要規范，命名，縮進等更不用說。看了這一章，我才知道一個注釋要如何寫才能讓人通熟易懂。在平常的編程里，我的注釋大多都是在變量名的后面，標注了該變量是什么。突然覺得這樣的做法很傻逼逼，一個變量，其實要是命名得好，那么一眼就知道這個變量做了什么，根本無需注釋。
2） p63--斷言是什么？
百度曰： 編寫代碼時，我們總是會做出一些假設，斷言就是用於在代碼中捕捉這些假設。斷言表示為一些布爾表達式，程序員相信在程序中的某個特定點該表達式值為真，可以在任何時候啟用和禁用斷言驗證，因此可以在測試時啟用斷言而在部署時禁用斷言。同樣，程序投入運行后，最終用戶在遇到問題時可以重新啟用斷言。使用斷言可以創建更穩定、品質更好且 不易於出錯的代碼。當需要在一個值為FALSE時中斷當前操作的話，可以使用斷言。單元測試必須使用斷言（Junit/JunitX）。
我並不怎么明白，對於沒有實踐過，只有理論的新事物，我們通常都很迷糊，似懂非懂。當我們真正運用到了，再回去看這些概念，可能一切才恍然大悟。真的，我們需要學的“新”事物實在太多了。
3）在上一篇博客中，我們便是做了結對編程。感覺兩個人做起事情來還是要比一個人輕松的，無論是編程上還是氣氛上。但是我卻無法想象，要是三個人，四個人…一個團隊的人該如何合作。（也就是第五章的團隊合作。）
第五章：團隊和流程
1）看了很多軟件團隊的模式，有主治醫生模式，明星模式，社區模式等等。以及功能團隊模式，有官僚模式。開發流程有寫了再改模式等。但是，可能是我拜讀不深吧，看完還是么能理清團隊如何合作，團隊里的每一個人負責什么。要一起寫需求設計嗎？還是一部分人負責？有沒有具體的例子可以幫助理解呢。一個公司開發一個大項目，要如何才能讓一個軟件團隊有條不紊等工作，他們之間如何分工，如何把所有人所負責的部分整合成一個項目？