第一章概論
通過第一章，我大概瞭解我將要從這本書中學習什麼，如何落實學習。本書的作者——鄒老師，通過設定簡單的人物和簡短的話語，使得書本遠離枯燥無味，同時還條理清晰，這加強了我看書的耐心。
1.1節通過3個簡短的對話和一個生活例項，啟發我對什麼是程式，什麼是軟體，什麼是軟體工程，沒有使用到演算法需不需要學習、掌握，軟體和演算法，資料結構有無關聯等問題的思考。仔細想想發現自己對這些概念模糊，毫無理解。通過繼續往下看，我才漸漸的明白了一行行的程式碼是源程式，能滿足各種功能的是應用軟體，能保證維修的是軟體服務…..也瞭解到了一個軟體不是簡簡單單就能說寫就寫的，還需要考慮各種因素，如人們的需求，功能的可行性。當軟體團隊通過通力合作，克服重重困難寫出軟體後，需要考慮軟體應用問題，是免費提供他人使用，還是收費，還是設有不同的版本再進行收費，這時候我不僅僅要了解什麼是軟體，還需要知道什麼的軟體企業的商業模式，要好好的遵循軟體行業的職業道德規範。
1.1.2節通過介紹航空的發展階段，我明白了軟體的發展和其差不多，一樣需要從有想法到動手實現，再到不斷探索，改進，擴大，形成一個成熟的體系。通過商業軟體和愛好者程式，加強了我對商業軟體開發的重視，明白開發軟體不能隨心而行，要多從客戶的角度出發，考慮問題，只有充分考慮全面，才能快速解決突發情況，減少使用者損失。只有自己能善於發現問題，解決問題時，才能使得自己更進一步，而不是停留練習階段。
1.2節詳細的給軟體工程下定義，介紹軟體工程的特殊性，介紹軟體工程中的“工程”的由來，講述了軟體工程與電腦科學的關係，軟體工程的知識領域，強調了軟降工程的目標——建立“足夠好”的軟體等等，告訴我軟體開發中應用工程化原則的重要性；軟體工程的魅力；不僅僅要學習好軟體工程的知識還要將它和其他學科聯合起來學習思考，還要多看書，多多瞭解軟體工程的知識領域，使得自己強大起來；在開發軟體時，結合時間，客戶需求，爭取在最適合的時刻開發出“好”的軟體。
問題：1.1.2最後提到合格的軟體工程師，有什麼具體的標準嗎？還是說能寫程式碼，又能發現問題解決問題就可以成為了呢？我們現階段可以從哪方面開始培養自己的開發思維和能力，向工程師邁進？
第二章個人技術和流程
如果說第一章我還有點概念，那麼第二章我可以說一竅不通，什麼是VSTS，什麼是單元測試，什麼是迴歸測試，還是什麼是效能分析……好多的新名稱，第一次看見，是那麼的沒有頭緒。要不是百度了，僅僅看書，我完全不知VSTS——Visual Studio Team System，是由微軟開發的一套具有高生產力、高整合性、可擴充套件的生命週期開發工具。
2.1.1節圖文並茂的告訴我，單元測試重要作用，可能是自己的能力不足，相關知識瞭解的太少了，一邊看還一邊想，單元測試怎麼寫？寫在哪裡？什麼時候寫？就算是按照書本上的程式碼寫，那又用什麼工具寫？
當全部看完時，我才明白了一點點，可以用VSTS來編寫單元測試，VSTS能為我們提供單元測試的基本骨架；知道單元測試對程式設計程式是很重要的；在編寫規格說明書時，最好能詳細規劃單元測試；編寫時有單元測試的相關步驟，1.設定資料2.使用被測試型別的功能3.比較實際結果和預期的結果。我們在編寫時要注意單元測試中的類庫，要相對應。
2.1.2節通過清晰的排版強調了一個好的單元測試的標準是如何產生的。這一小節告訴我：單元測試是在最低的功能或是引數上驗證程式的正確性，在一般情況下，單元測試必須由最熟悉程式程式碼的人來編寫，每一個單元測試過後，都不受上一個的影響…..
2.1.3迴歸測試，我一看到這這個詞語，還以為是將所以的單元測試都放入程式中進行整合，校驗。沒想到其本意是為了避免程式迴歸到原來不正常的狀態，把所有發現並修復的bug找出路，一個個驗證的大規模的全面的測試。
從2.2節中，我瞭解到效能分析，本書通過一個例子介紹了VSTS提供了效能分析工具。效能分析的兩種方法：抽樣和程式碼注入。這兩種方法各有優缺點，所以我們要將兩者結合使用，達到最優。本章節有許多的效能分析名詞，需要我有所瞭解，才能體會書本所提到的專有名詞。在效能分析時，我們要結合實際報告看程式碼被呼叫的次數，瞭解到它們的耗時間長短，要善於思考，解決某部分程式碼耗時長的問題，還要考慮某部分的程式碼所佔時間的比例，不可盲目優化。2.2中的提到的Release版本和Visual Studio，我都百度了一下，感覺有點深奧，不太瞭解。
2.3個人開發流程，通過書本上大四學生和已工作3年的軟體工程師的任務清單，我瞭解到從學生磨到職業的程式設計師，不僅僅是指編寫程式碼時能高效率，更是不侷限於某一種軟體技術，有開發流程意識，花更多的時間來收集資料後，分析提高。
2.4大節叫我們動手實踐，但我未能將書本上的知識瞭解清楚，不知道如何下手，希望VSTS寫的單元測試的例子能再詳細點，再多一點。
問題：a.2.1.2中提到的程式碼覆蓋率是指單元測試能將程式中所有的程式碼都覆蓋了，還是將程式碼實現的功能路徑都實現，或是另有解析？
b.2.1.2中提到的單元測試應該整合到自動測試的框架中，這是如何實現的呢？
C.2.1.2中提到單元測試必須和產品程式碼一起保護和維護，我的理解的單元測試是在VSTS中編寫的，產品程式碼是在某一技術軟體編寫的，那這兩者是如何統一管理？
第三章軟體工程師的成長
看了前面兩章，我感覺我現階段距離一個程式設計師還很遠，軟體工程師更是遙不可及。在學校的我學習了很多，如c語言，資料結構，物件導向……學的多而不精，前路迷茫，縱觀現在我就是一個盲目學習的學生，上課時認真聽了課後卻沒有花更多的時間去研究，遇到不懂的容易掉價死衚衕，總是花很多時間悶悶思考，不到最後都沒有去請教同學，去百度。看著做程式的人，都好厲害，自己就只能在一旁羨慕嫉妒恨。那現在在怎麼樣才能將自己對程式設計的興趣提高，加強自己的程式設計思想?提高自己的價值?
書本上提到初級的軟體工程師所需的基本條件，
1.要積累軟體開發的相關知識，提高技術技能；
2.要積累問題領悟的知識和經驗；
3.要對通用的軟體設計思想和軟體工程思想的理解；
4.提高職業技能
5.實際成果。
從1成長到5需要時間的積累外，還需要加強自己的學習力，這對現階段的我將是一個漫長的過程。在這個過程中，我要樹立正確的學習意識，對待每一個程式都要學會分析，要了解自己所程式設計的程式有多大，規劃自己計劃完成時間並於實際完成時間相對比，注重完成的質量。盡全力的將自己的軟體工程師的道路建立起來。
問題：若以後畢業了，剛剛出來的我們僅僅憑藉在校學習的知識是遠遠不夠的，一般公司招聘時都會要求有一兩年的工作經驗或是說有經驗的優先，那我們應屆生該如何加強自己的價值？公司需要的是為其創造價值的人才，還有機會讓我們慢慢學習嗎？
第四章 兩人合作
通過結對合作，令我意識到了編寫程式不僅僅要自己能明白，也要便與他人檢視和理解自己的程式。
4.1大節提到的程式碼規範，我們編寫程式碼時要注重程式碼風格規範和程式碼設計規範，無論是類名，物件名，縮排還是行寬什麼的，在結對子程式設計時都要有所規定，不然到後面出現的類或是物件多了，就很容易混亂，分不清楚誰是誰。要學會封裝，編寫函式，將功能模組具體化，減少主方法裡面的程式碼，避免大規模的出錯。
4.4中提到了程式碼複審，在平時程式設計程式時，我也會從頭到尾的檢視自己的程式碼，執行程式，若是多次結果相同，無誤就可以了。沒有想過發現程式碼錯誤外，還去思考邏輯是否有誤，演算法夠不夠優化等其他問題。他人能否覺得我所編寫的程式是否簡單易懂，能否從中學習。
4.5結對程式設計，兩人合作，一同思考一同編寫程式，有利於提高效率，相互學習。所以要學會4.6節提到的合作的不同階段和技巧，一開始探索專案時，中途遇上不可解決問題時，後期簡單的複查時，可以獨立思考，期間思路清晰，溝通良好時，一起結對編寫，加強合作。在合作中在客觀全面的對待自己的結對夥伴，懂得相互鼓勵，相互學習。
問題：a.本章4.3.3中的錯誤處理和第二章提到的單元測試一樣嗎？
b.本章4.3.3中提到的斷言是什麼？僅僅從書上寫的程式碼，我理解就是判斷語句，這樣的理解可以嗎？
第五章 團隊合作
結對程式設計，兩個人好交流意見，產生分歧不大，換做是團隊合作會怎麼樣呢？會不會尚未從結對程式設計中脫離出來，對團隊合作感到混亂，不會分工，不便於交流？所以我們要學會需找合適的團隊合作模式和開發流程。書本上提到了很多的團隊合作模式和開發流程，都各有優缺點。僅僅從校園合作的角度出發，我認為使用功能團隊模式更適合彼此合作交流，而開發流程在校園合作階段，容易被忽視或是考慮的不全面，大夥要著重培養。
問題：a.團隊合作模式和開發流程的關係密切？兩者能否脫離？