1.這次我閱讀了關於團隊合作的那部分構建之法。
正好老師也要求了我們兩人結隊合作做乙個網頁版的小學生四則運算，雖說工程的比較簡單，但是對於剛接觸製作網頁的知識的我們編起來還是比較吃力的，剛開始我們就大致分配好了兩個人的任務，隊友的html語言知識學的比較好，大部分的頁面都是她做的，我負責最後的美化和整個工程的構思還有計時的功能，我們的任務量分配的都差不多，比較均勻，一開始都是各做各的任務，沒有任何交流，所以剛開始就碰到了做頁面的時候的美化問題，還有一些想法不一致的問題，兩個人就一下子懵了，整個進度就沒有什麼進展，因為各想各自的，看到的總會有侷限，到最後交作業比較迫切了，兩個人就開始進行交流合作，一起編寫，思考，最後還算完美的完成了此次作業。從這次的結對合作中我明白了乙個道理，做軟體的不能一味的侷限在自己，溝通很重要，不能一味的按照自己的想法，一定要多學，多問，多溝通交流，這就是乙個軟體專案團隊之所以存在的道理，眾人拾柴火焰高，團結起來力量大。
2. 每個人在各自獨立設計、實現軟體的過程中不免犯這樣那樣的錯誤。在結對程式設計中，因為有隨時的複查和交流，程式各方面的質量取決於一對程式設計師中各方面水平較高的那一位。這樣，程式中的錯誤就會少的很多，程式的初始質量會高很多，這樣會省下很多以後測試、修改的時間，具體來說，結對程式設計有一下好處：
3.1.在開發層次，結對程式設計能提供更好的設計質量和**質量，兩人合作解決問題的能力更強。兩人合作，還有相互激勵的作用，共曾是看到別人的思路和技能，得到實時的講解，受到激勵，從而努力提高自己的水平，提出更多創意。
2.對開發人員自身來說，結對工作能帶來更多的信心，高質量的產品能帶來更多的滿足感。
3.在企業管理層次上，結對能更有效的交流，相互學習和傳遞經驗，分享知識，能更好地應對人員流動。
1.這次我閱讀了關於團隊合作的那部分構建之法。
正好老師也要求了我們兩人結隊合作做乙個網頁版的小學生四則運算，雖說工程的比較簡單，但是對於剛接觸製作網頁的知識的我們編起來還是比較吃力的，剛開始我們就大致分配好了兩個人的任務，隊友的html語言知識學的比較好，大部分的頁面都是她做的，我負責最後的美化和整個工程的構思還有計時的功能，我們的任務量分配的都差不多，比較均勻，一開始都是各做各的任務，沒有任何交流，所以剛開始就碰到了做頁面的時候的美化問題，還有一些想法不一致的問題，兩個人就一下子懵了，整個進度就沒有什麼進展，因為各想各自的，看到的總會有侷限，到最後交作業比較迫切了，兩個人就開始進行交流合作，一起編寫，思考，最後還算完美的完成了此次作業。從這次的結對合作中我明白了乙個道理，做軟體的不能一味的侷限在自己，溝通很重要，不能一味的按照自己的想法，一定要多學，多問，多溝通交流，這就是乙個軟體專案團隊之所以存在的道理，眾人拾柴火焰高，團結起來力量大。
2. 每個人在各自獨立設計、實現軟體的過程中不免犯這樣那樣的錯誤。在結對程式設計中，因為有隨時的複查和交流，程式各方面的質量取決於一對程式設計師中各方面水平較高的那一位。這樣，程式中的錯誤就會少的很多，程式的初始質量會高很多，這樣會省下很多以後測試、修改的時間，具體來說，結對程式設計有一下好處：
3.1.在開發層次，結對程式設計能提供更好的設計質量和**質量，兩人合作解決問題的能力更強。兩人合作，還有相互激勵的作用，共曾是看到別人的思路和技能，得到實時的講解，受到激勵，從而努力提高自己的水平，提出更多創意。
2.對開發人員自身來說，結對工作能帶來更多的信心，高質量的產品能帶來更多的滿足感。
3.在企業管理層次上，結對能更有效的交流，相互學習和傳遞經驗，分享知識，能更好地應對人員流動。
《構建之法》閱讀筆記（2）
構件之法 閱讀筆記2 第二章提及不同的測試，其中有單元測試 回歸測試和效能分析。單元測試是一種讓自己負責的模組功能定義盡量明確，模組內部的改變不會影響其他模組 而且模組的質量能得到穩定的量化的保證的很有效的解決方案 回歸測試可以理解為 回歸到以前不正常的狀態 所進行的測試。針對乙個bug fix也要...
構建之法閱讀筆記（2）
這一周我又閱讀了構建之法的後面幾章，覺得這本書的想法和思維方式很新穎，值得讓人思考。第二章講述的是個人技術以及個人軟體的開發流程，首先告訴了我們單元測試的重要性，例如，乙個人寫的模組被其他人寫的模組呼叫。軟體的很多錯誤都 於程式設計師對模組功能的誤解 疏忽或者不了解模組的變化。如何能讓自己負責的模組...
構建之法閱讀筆記2
重要的單元測試 有效解決程式設計師對模組功能的誤解 疏忽或不了解模組的變化之類的問題，使自己負責的模組功能定義盡量明確，模組的質量得到穩定的 量化的保證。好的單元測試的標準 在最基本的功能 引數上驗證程式的正確性 單元測試必須由最熟悉 的人 程式的作者來寫 單元測試過後，機器的狀態保持不變 單元測試...