項目總結－結對程式設計

在項目中，我們實行了結對程式設計，獲得了一定的成功：

1、  職業态度有很好的改進。由于缺少了單人獨處的環境，兩個人的合作更專注于工作，職業态度是程式設計人員的首要精神，對代碼的品質起關鍵作用。員工聊QQ的、看新聞的、不務專業的、工作義務式的現象沒有了。取而代之的是工作變的積極，學習也熱情了，并且充滿成就感。如果有很好的企業文化來配合，例如進行一些合作性的運動，足球，籃球等，更能促進職業态度改進，達到以團體帶動個體的效果。

2、  1＋1>2。結對程式設計，在每一時刻都是一個程式員在程式設計，說效率如何高，也隻是1+1>1，但是否大于2呢？答案是肯定的。首先，一個人的程式設計，平均很難實作1>80%×1的工作效力。但是在和同伴一起工作時，必須保持思維一直高度集中，是以平均都可以達到1>80%×1的個人效力，同時有了一遍代碼評審，使得出錯幾率就降低，減少了bug的産生。也由于兩個人的思想彙集，能創造了很多新程式設計算法或結構重用等。是以着眼于整個項目來看，這個實踐确實大大提高了效率。

3、  軟體品質有明顯的改進。

1）  代碼的壞味道減少。首先是對編碼的規範的遵守。結對程式設計改掉了一些人的編碼的壞習慣（例如：不注釋），也同時融合了每個人的程式設計優點。其次，代碼的層次，和文法變得優美了。一些不耐煩的代碼沒有了，一些重複出現的代碼沒有了，改重用的代碼重用了，改重構的代碼重構了。

2）  程式執行效力提高了。結對程式設計是兩個人的腦力勞動，可以互相學習，互相研究，是以我們在一起，常常會去試驗新的編碼方式，以尋找最好的方法。而且有什麼想法通過交流後兩個人都覺得可行，就可以寫出測試用例，再來寫出實作；是以不論在解決問題的時間和方法上，都比以前做得更快更好。

3）  減少了bug的産生。Bug的産生首先在于了解上，兩人程式設計，需要兩人去了解，同時兩個人要經過讨論，形成一緻思想，才可以程式設計，使得在了解錯誤的風險上減少。其次兩人程式設計就等于已經有了一遍代碼評審，出錯幾率降低了很多。是以結對程式設計能有效的減少了bug的産生。

當然，在結對程式設計的過程中，也遇到了一些困難

1、  如何将結對程式設計有效的融合到開發流程中

我們團隊加上項目經理和美工，一共6人，可以有2組配對（不包括經理，美工）。開發流程如下：

開發階段	描述
需求	搜集需求，使用者用例模組化。
分析	功能分析，将系統分解成子產品，并定義子產品的功能；進行系統用例模組化。
設計	結構設計，界面設計，資料庫設計
編碼	編寫程式。包括了白盒測試代碼的編寫
測試	內建，功能，黑盒測試。

那麼如何進行結對開發呢，在那些流程中結隊開發呢？

1)        我們進行以子產品為機關，即是一組人負責一個子產品的設計，和編碼

2)        盡量将性格融合的，技術互補的配對。并且在不同階段，有針對性的組合，可以起到很好的作用。比如，一個嚴謹，謹慎的人，配上一個喜歡創新的人。

3)        兩人中，地位是平等的，隻有經驗多寡之分，沒有地位高低之分

4)        工作時，兩人必須使用一台電腦，一天中必須要有大于4小時的合作時間，即是要最少共同工作半天。

5)        将項目中的難點,配置設定給搭配默契并且經驗豐富的組去負責。

6)        分析設計時，由兩人讨論通過并簽名。（在項目讨論會上必須由兩人講解）

7)        編碼前，兩人必須有達成共同的思想

8)        編碼時先寫測試，再寫實作

9)        任務出錯或不能完成，應由雙方共同負責，不能互相指責

10)     兩人意見不同時，可由上司幫助解決，最好不要各執己見

11)     每次測試時，從新組合配對人員，但不能由設計編碼的人負責測試自己編寫的子產品但可以寫測試文檔。

12)     上司多點鼓勵，結對人員互相鼓勵，可以産生共同的榮譽感，責任感。

這是我們項目配對的情況

子產品1	子產品2	子產品3	……
設計	張三，李四	王五，吳六	張三，李四	……
編碼	張三，李四	王五，吳六	張三，李四	……
第一次測試	張三，王五	李四，吳六	李四，吳六	……
第二次測試(回歸測試)	王五，吳六	張三，李四	王五，吳六	……

項目完成後，統計了結對程式設計與沒有結對程式設計的資料對比。

結對程式設計	沒有使用結對程式設計
A項目	B項目
設計	兩人4.28天/子產品 (共2組15天7子產品)	一人4.17天/子產品 (共2人25天12子產品)
編碼	17.00k/兩人/天(1088K/2組/32天)	8.16k/人/天(1372k/4人/42天)
測 試	Bug數	13個	61個
測試天數	6天	19天
回歸次數	2次	3次
合計	53天	86天

注：A項目與B項目在規模上和複雜度上相差不大。 

對上表進行分析得到以下結論

1）               設計階段，結對程式設計比沒有使用結對程式設計慢。因為，兩人的讨論更多，想法更多，方案也更多，設計的也更加全面。盡管慢，但是效果和品質明顯比沒有使用結對程式設計的品質好。

2）               編碼階段，結對程式設計比沒有使用結對程式設計快。我想主要展現在兩人可以保持思維一直高度集中，和對遇到問題解決的速度上。并且是一個逐漸融合的過程，兩人融合的快，編碼的速度也快。

3）               測試階段，結對程式設計比沒有使用結對程式設計快。從Bug數可以肯定，結對程式設計對軟體品質有所提高。在測試時間上也縮短，得益于bug數的減少，修改時間減少和回歸的次數減少。

2、  結對程式設計中兩人不合作問題。

在開始運作結對程式設計上，這個問題特别煩人。在新人中倒是很好解決，在公司呆的久的員工反成了問題。習慣了單打獨鬥的，旁邊有一個人總是顯的不習慣。還有，在性格上不是問題，大家都是一定文化層次的人，很容易融合。但是在生活上，反成了問題，比如一些壞習慣，個性等。我進行如下的解決方法

1）  營造團結，和諧，活躍的環境，讓大家多點自我表現的機會，使大家充滿自信，勇于發言，勇于表達自己的意見。

2）  多進行團體活動，下班打籃球，周末有空去一起喝茶聊天（從來沒有加班）。做集體運動，使其有共同目标，還互相了解，拉進距離。聊天可以輕松玩笑的指出一些人的壞習慣。

3）  多多對小組鼓勵獎勵，使他們有共同榮譽感，責任心。

4）  實在不行，就趕人吧！（我沒有用過）。

3、  結對程式設計中兩人程式設計水準問題。

這是很多人提問最多的問題，我很牛，也要結對嗎？又或者我是新手，可以結對嗎？其實結對程式設計的内涵為一種共享；一種技術，經驗，知識的共享。通過共同商讨、解決問題，來提高溝通，交流，來降低誤解和疏遠。是以這不是問題，問題的本身在于共享精神，要求大家沒有私心，要求大家互相幫助。不管菜鳥與菜鳥，或者老鳥與菜鳥，老鳥與老鳥的結對，都不會有問題。盡管兩人程式設計水準問題有所差異，那也是工作的方式不同罷了，專家級的兩個人，更多的是創新，一老一小，更多的是教育，兩個菜鳥那就是更多是在唱歌，就像過河的小馬。

最後，談談公司文化對結對程式設計的影響。首先要明白，不是什麼公司都可以進行結對程式設計。結對程式設計是XP的核心實踐之一，但很多人執懷疑态度和觀望态度。我覺得軟體公司的企業文化對是否能成功執行結對程式設計是一個關鍵因素。如果下面三個問題都回答是，你可以試試實施結對程式設計。

1、  是否有一個可以能暢所欲言的，和諧平等的，相對民主的環境？

2、  是否有一種互相交流，互相研究，共享代碼，共享知識的氛圍？

3、  是否緻力于一種共同成長，開放共享的學習型組織？