今天閱讀了《構建之法》的部分主要介紹了個人技術和流程。關於單元測試，鄒老師給了我們很多建議。工欲善其事必先利其器，或者說是磨刀不誤砍柴工，養成編寫單元測試的習慣不僅不會拖累開發進度，反而能讓我們的**更加高效。
軟體是由多人合作完成的，不同人員的工作相互有依賴關係。例如，乙個人寫的模組被其他人寫的模組呼叫。軟體的很多錯誤都**於程式設計師對模組功能的誤解、疏忽或不了解模組的變化。單元測試能讓自己負責的模組功能定義盡量明確，模組內部的改變不會影響其他模組，而且模組的質量能得到穩定的、量化的保證。很多調查顯示，在軟體開發後期發現的bug，修復起來要花更多的時間。
在單元測試的基礎上，我們就能夠建立關於這一模組的回歸測試。目的是1. 驗證新的**的確改正了缺陷2. 同時要驗證新的**有沒有破壞模組的現有功能。所以，對於「回歸測試」中的「回歸」，我們可以將其理解為「回歸到以前不正常的狀態」。回歸測試最好要自動化，因為這樣就可以對於每乙個構建快速執行所有回歸測試，以保證盡早發現問題。單元測試是回歸測試的基礎。在專注於模組基本功能的單元測試之外，還有功能測試—從使用者的角度檢查功能完成得怎麼樣。在微軟的實踐中，在乙個專案的最後穩定階段，所有人都要參加全面的測試工作，把所有以前發現並修復的bug找出來，乙個乙個驗證，以保證所有已經修復過的bug的確得到了修復，並且沒有在最後乙個版本中「**」，這是乙個大規模的、全面的「回歸測試」。
其實在上大學學習了程式設計之後自己從來沒有編寫單元測試的習慣。只是一通的編完之後立即編譯執行，然後等待報錯再一點點的查錯。這樣也許在之前的小程式面前看不出什麼，但是以後要編寫更複雜的程式，或者是參加工作之後，這樣的低效率立即會讓自己大吃苦頭的。
所以我要養成單元測試的習慣，從現在就培養自己的專業意識，認真的對待每一次程式設計，對每乙個模組都認真的編寫單元測試，扎扎實實的把自己的程式寫好。
還有就是程式設計的時候要注意**規範，**規範意味著乙個程式設計師的品德問題，自己雖然在這方面一直做的不錯，但是看到鄒老師如此強調，上課時聽到老師如此重視這一問題，還是提醒自己繼續保持。
02《構建之法》閱讀筆記02
個人感受 過去我的做法 1 以前每個部分都是分開各做各的，做好自己的事情就好了 不需要管其他的。獨立開發，想做什麼做什麼，只要實現布置的任務就行。這樣做的缺陷 無法做到團隊快速開發，很難提公升速度。問題解決方法 1 要自己挑選任務 每次sprint結束之後，還要總結不足，提出改進，並且自己要實施這些...
構建之法閱讀筆記02
第二章的開頭就給我講出了單元測試的概念和效果，單元測試可以使自己父子的模組功能定義盡量明確，模組內部的不會影響其他模組，而且模組的質量能得到穩定的，量化的保證。還舉例了小飛寫單元測試的例子，讓我們隊建立單元測試主要步驟印象深刻，建立單元測試的主要步驟 1.設定資料 2.使用被測試型別的功能 3.比較...
構建之法閱讀筆記02
今天看了第六章敏捷流程，在裡面我看到了衝刺執行任務中的每日例會，在這裡身份的類似於主人暑假給我們布置的任務和發表部落格的要求，其中這裡面有三條內容，分別是我昨天做了什麼，今天做了什麼，在其中又遇到了什麼問題。這個寫問題只有在衝刺階段真正的做了，用心的去解決了，才會真的有收穫 相反這些流程也會流於形式...