一．Pair work的得與失
合作編程在以前的學習過程中也進行過，基本也就是各人負責一部分最后再將之拼湊起來，而這次作業要求的雙人合作，要求的並不是這樣，而是兩人應該在一起進行工作，這樣的要求理想情況下能在代碼編寫時提供更高的設計質量和代碼質量，也能讓結對人員之間做到相互學習，經驗共享，促進交流，但是在實際情況中，因為結對對象並不是自選，我們之間的共同的空閑時間（因為課程，生活習慣等）不能得到保障，而在另一方面，合作對象之間的相互熟悉也花去了不少的相同的空閑時間，整體效率上也並不見得比分開工作效率高。
而在我理解起來，pair work要想要高效率的運作起來，結對對象的選擇是一個很重要的部分，相比與還需要相互熟悉的之前較少交流的同學，或許室友什么的溝通起來更為方便，空閑時間也更為統一，而至於老師在課上所說的“pair work中兩人相互督促”，不是在一個寢室的同學的督促無論是次數還是效果肯定是比不上同寢室的室友的。
疑問：pairwork中工作分量不平衡難道不會影響工作配合么，雖說我們pairwork只合作一次，但是在實際中未必不會出問題么？
二．代碼規范的思考
這其實是我們目前編程中最需要學習的。在以往的學習過程中對程序的規范性要求並不高，更注重的是輸出的結果，實現的功能，因此某些變量，方法的定義就很難擺脫常用的a,b,c,d,t1,t2,t3。這樣的程序不僅他人閱讀困難，就算是自己也難免在一段時間之后讀不懂自己寫的程序。
空行，縮進，下划線，大小寫以及注釋的問題，之前編程中或許注意過，但也並沒有得到過比較系統化的規定，尤其是注釋，一般都是想起來就寫上兩句，沒注意就算了。在學習完代碼規范這章后，雖然對自己編程能力上提升不大，但是對自己在編程規范上了解的空白有了一定的彌補，受益匪淺。
三．效能分析
其實這也應該是在編程過程中自己摸索出來的經驗，但同樣是由於之前並沒注重這方面，因此在代碼效率上個人做得並不好。
就如同書上所舉的例子，for(int i=0;i<m_wordlist.count;i+)，其中m_wordlist.count調用次數相當高，但如果改成int count= m_wordlist.count;for(int i=0;i<count;i+)的話，效率將提升不少，而就這點，反觀自己第一次wordcount作業中，如：
for (int i = 0; i < dat.Length; i++)
for (int i = 0; i < saveload.begin_a.Length; i++)
for (int m = 0; m < saveload.name.Count - 1; m++)
等等情況出現的次數絕對不少，這種類似躺槍的感覺着實讓人慚愧。但另一方面來說，這些約定俗成或者說是慣例的東西也並沒有在初學時期就說過，在不良好的編程習慣養成后被指責編程風格不對，代碼效率低，代碼不規范，這對我們來說也是相當的無奈。
疑問：這應該是二，三一起的疑問，代碼規范與提高效率的技巧應該在初學的時候就提出，而且應該是系統話規范化的提出，而現在只是在編程過程中讓我們自己摸索？
四．測試與用戶測試
書上也並為給出特殊的測試方法，不過其中一點——單元測試需要也必須由程序開發人員來進行。一方面是有些問題在部分代碼完成時測試很容易發現，但是在整個工程完成之后卻難以尋找，會極大的降低測試人員的工作效率與工作熱情；另一方面則是態度上的問題——並不是說代碼寫好了，編譯不出錯就算工作完成了，自己的模塊要能正確運行才算是完工。比起讓他人來研究開發人員的代碼，要適應不同的編程風格，弄清楚代碼的意思所需要的時間暫且不談，這也難免讓開發人員產生“反正有人來測試”的不負責任的心理。
而用戶測試則要求更高，各種神奇/奇葩的情況下都需要考慮到，而且最重要的一點是這些還未必會在用戶需求中出現，“如果用戶這樣這樣，會出現什么情況”，如果“用戶輸入那個，又會怎樣”，這固然是要求開發人員在寫代碼的時候就將情況考慮周全，但另一方面來說人本身就難免出現紕漏，因此就有了后續測試的必要。而后續測試中要如何做到周全？就算是做到100%代碼覆蓋，也不能保證100%的正確性，所以才會有各種補丁的不斷出現，所以才會有各種版本的更新…
總而言之，寫代碼和做其他事也沒有什么區別，負責和擔當總是需要的。
疑問：感覺如何接收用戶的反饋才是問題所在，很多情況下用戶只會說有問題，假設在開發過程中並沒發現問題，但實際上存在問題，那么如何加上報錯機制方便接受用戶反饋？
五．團隊開發的若干
規則是死的，人是活的。當然MSF的那一套流程確實是成功經驗的總結，但是在實際中能做到什么程度又是另一個未知數了。
在按標准流程走不下去的情況下，我們需要考慮哪些呢？團隊項目的最困難的地方就是按時完成任務與隊員間的溝通，其實那一套流程為的也就是保障這兩點，也還好teamwork中各成員也都比較熟悉，估計相互督促溝通也不會太過於困難。
疑問：這只是針對我們學生的team而言，我們並不是專業開發團隊，我們是否可只借鑒MSF中若干部分/按我們自己覺得方便的方式來開展我們的活動？
一．Pair work的得與失
合作編程在以前的學習過程中也進行過，基本也就是各人負責一部分最后再將之拼湊起來，而這次作業要求的雙人合作，要求的並不是這樣，而是兩人應該在一起進行工作，這樣的要求理想情況下能在代碼編寫時提供更高的設計質量和代碼質量，也能讓結對人員之間做到相互學習，經驗共享，促進交流，但是在實際情況中，因為結對對象並不是自選，我們之間的共同的空閑時間（因為課程，生活習慣等）不能得到保障，而在另一方面，合作對象之間的相互熟悉也花去了不少的相同的空閑時間，整體效率上也並不見得比分開工作效率高。
而在我理解起來，pair work要想要高效率的運作起來，結對對象的選擇是一個很重要的部分，相比與還需要相互熟悉的之前較少交流的同學，或許室友什么的溝通起來更為方便，空閑時間也更為統一，而至於老師在課上所說的“pair work中兩人相互督促”，不是在一個寢室的同學的督促無論是次數還是效果肯定是比不上同寢室的室友的。
疑問：pairwork中工作分量不平衡難道不會影響工作配合么，雖說我們pairwork只合作一次，但是在實際中未必不會出問題么？
二．代碼規范的思考
這其實是我們目前編程中最需要學習的。在以往的學習過程中對程序的規范性要求並不高，更注重的是輸出的結果，實現的功能，因此某些變量，方法的定義就很難擺脫常用的a,b,c,d,t1,t2,t3。這樣的程序不僅他人閱讀困難，就算是自己也難免在一段時間之后讀不懂自己寫的程序。
空行，縮進，下划線，大小寫以及注釋的問題，之前編程中或許注意過，但也並沒有得到過比較系統化的規定，尤其是注釋，一般都是想起來就寫上兩句，沒注意就算了。在學習完代碼規范這章后，雖然對自己編程能力上提升不大，但是對自己在編程規范上了解的空白有了一定的彌補，受益匪淺。
三．效能分析
其實這也應該是在編程過程中自己摸索出來的經驗，但同樣是由於之前並沒注重這方面，因此在代碼效率上個人做得並不好。
就如同書上所舉的例子，for(int i=0;i<m_wordlist.count;i+)，其中m_wordlist.count調用次數相當高，但如果改成int count= m_wordlist.count;for(int i=0;i<count;i+)的話，效率將提升不少，而就這點，反觀自己第一次wordcount作業中，如：
for (int i = 0; i < dat.Length; i++)
for (int i = 0; i < saveload.begin_a.Length; i++)
for (int m = 0; m < saveload.name.Count - 1; m++)
等等情況出現的次數絕對不少，這種類似躺槍的感覺着實讓人慚愧。但另一方面來說，這些約定俗成或者說是慣例的東西也並沒有在初學時期就說過，在不良好的編程習慣養成后被指責編程風格不對，代碼效率低，代碼不規范，這對我們來說也是相當的無奈。
疑問：這應該是二，三一起的疑問，代碼規范與提高效率的技巧應該在初學的時候就提出，而且應該是系統話規范化的提出，而現在只是在編程過程中讓我們自己摸索？
四．測試與用戶測試
書上也並為給出特殊的測試方法，不過其中一點——單元測試需要也必須由程序開發人員來進行。一方面是有些問題在部分代碼完成時測試很容易發現，但是在整個工程完成之后卻難以尋找，會極大的降低測試人員的工作效率與工作熱情；另一方面則是態度上的問題——並不是說代碼寫好了，編譯不出錯就算工作完成了，自己的模塊要能正確運行才算是完工。比起讓他人來研究開發人員的代碼，要適應不同的編程風格，弄清楚代碼的意思所需要的時間暫且不談，這也難免讓開發人員產生“反正有人來測試”的不負責任的心理。
而用戶測試則要求更高，各種神奇/奇葩的情況下都需要考慮到，而且最重要的一點是這些還未必會在用戶需求中出現，“如果用戶這樣這樣，會出現什么情況”，如果“用戶輸入那個，又會怎樣”，這固然是要求開發人員在寫代碼的時候就將情況考慮周全，但另一方面來說人本身就難免出現紕漏，因此就有了后續測試的必要。而后續測試中要如何做到周全？就算是做到100%代碼覆蓋，也不能保證100%的正確性，所以才會有各種補丁的不斷出現，所以才會有各種版本的更新…
總而言之，寫代碼和做其他事也沒有什么區別，負責和擔當總是需要的。
疑問：感覺如何接收用戶的反饋才是問題所在，很多情況下用戶只會說有問題，假設在開發過程中並沒發現問題，但實際上存在問題，那么如何加上報錯機制方便接受用戶反饋？
五．團隊開發的若干
規則是死的，人是活的。當然MSF的那一套流程確實是成功經驗的總結，但是在實際中能做到什么程度又是另一個未知數了。
在按標准流程走不下去的情況下，我們需要考慮哪些呢？團隊項目的最困難的地方就是按時完成任務與隊員間的溝通，其實那一套流程為的也就是保障這兩點，也還好teamwork中各成員也都比較熟悉，估計相互督促溝通也不會太過於困難。
疑問：這只是針對我們學生的team而言，我們並不是專業開發團隊，我們是否可只借鑒MSF中若干部分/按我們自己覺得方便的方式來開展我們的活動？
六. 其他
這只是書中一個小故事，“劫匪與絞刑架”——如果沒有絞刑架，劫匪就不用有所顧忌了，但另一方面，劫匪的數量也必然增多，導致劫匪也越來越不好混。當然可以把這個故事理解為對目前我國計算機行業的一個幽默的詮釋，現在就算是三本大學照樣有個計算機專業，這樣的泛濫導致所謂“計算機專業”學生也愈加普遍，那我們與那些泛濫普遍的“同行們”的區別就在於我們在大學期間所受到的教育與我們所能學到的東西。
“碼農” 這個詞的出現無疑是代表低水平的程序員越來越“不好混”了，因此我們的出路也就是盡量提高自己的技術水平，跨過那道划分優劣的門檻，因此就算是在teamwork中，提升個人的技術水平也是對整個teamwork進展的一大助力。當然在VSTS開發中，如果人人都能獨當一面或者說干脆每個人都能獨立完成這個項目，那各種團隊開發的條條框框自然沒任何價值，但是在實際情況中MSF所指出詳細流程與具體方法確實值得我們學習參考。
疑問：那么是否可以考慮在團隊工作結束后把團隊成員在工作中得到的提高也算入個人成績組成的一部分。
七. 敏捷開發有感
這個是晚上在博客園首頁看到的某篇談論開發過程中敏捷開發模式后，又想到之前看到教材BLOG里所想到的。其價值觀——溝通、簡單、反饋、勇氣，謙遜聽起來感覺着實空洞，簡單說起來還是上文中說過的兩點，責任與溝通，如此文中所示，其實敏捷開發與我們本身習慣的流程差別不大，其更重要的應該是將開發中所需要的原則明確的提出來了，而不是早上一次例會，晚上一次總結的形式。