第一次嘗試結對程式設計的心得體會

時間＼2017-08-16

我的直接主管是來自臺灣的Ben，他非常喜歡探索新的開發模式，

其中有一次他讓我這個只有一年開發經驗的人新人和一個工作三四年的工程師一起做結對程式設計。

和我一起結對的程式設計的L先生是一個經驗非常豐富的老工程師，他寫的代碼品質、效率極高，跟他一起學了很多好的程式設計習慣

第一次嘗試採用結對程式設計（Pair Programming）這種程式設計模式，雖然時間不長，但還是感覺體會頗多，拿出來與大家分享一下。

一、結對程式設計的優勢

1.發揮”雙劍合璧”的威力

俗話說”三個臭皮匠，勝過一個諸葛亮”，大家在做同一件事時，集思廣義發揮各自優點，可以使我分析更能切中要害。

比如在設計階段，我們其中一個人想到採用策略模式來解決這個問題，採用一個介面作為抽象行為層。

另外一個人發現我們這些具體的演算法類有一些公用行為，於是考慮用抽象類別代替原來的介面作為抽象行為層，

這樣可以把那些公用行為上移到抽象層，大大減少了冗餘碼，使設計變得更加優雅。

2.相互督促，不間斷的Code Review,提高代碼品質

相互督促可以使我們都能集中精力，更加認真的工作，我們對業務的理解深度相差無幾，設計在我們共同討論中產生，這樣我們在進行Code Review的時候比起傳統的方式就會更有效。

比如我們其中一個人，按照我們共同完成的活動圖去程式設計，完成一小段邏輯後，

另外一個人會馬上給出意見，說出代碼存在的潛在問題，這個潛在的問題，很可能是因為我們當時對業務理解存在偏差造成的。

很可能這個時候我們要對設計進行改動以適應業務。如果是一個人在程式設計，恐怕很難找到這樣的問題，傳統的Code Review也很難做到這一點。

任何一段代碼都至少被兩雙眼睛看過，兩個腦袋思考過，代碼的品質會得到有效提高。

3.相互學習和傳遞經驗

“三人行必有我師”，相互學習對方的技能，可以提升自己水準。比如我們需要透過一個SQL語句去查找一組多次變更的合同。

這時候需要用到遞迴的SQL語句,其中一個人不熟悉，另外一個則對此駕輕就熟，於是很快另外一個人也就掌握了這種SQL語句的寫法。

再比如我們在進行編碼時可能會用到一些IDE的特性以提高我們的編碼速度，比如一些快速鍵的使用、抽取方法的使用，

可能其中一個人不太熟悉這些IDE的特性，透過他的夥伴也就很快掌握了，大大提高了生產力。

4.可以更加愉快的工作

提醒：如果兩個人都是喜歡閒聊者，請不要選擇結對程式設計

二、結對程式設計的劣勢

1.有效的結對程式設計，需要一定的磨合時間

結對程式設計之初，我們兩個的配合還是有些不順暢，使用IDE的習慣有差異，編碼習慣有差異，甚至對某個詞語的表達方式都存在差異，會影響到我們的效率。

正當我們相互磨合漸漸適應對方，我們的任務也基本結束了。

2.溝通各自意見，需要時間

兩個人一起程式設計難免出現意見不一致的現象，出現這種情況我們採取的方式是停止手頭的工作，直到討論清楚得出結論為止，有時候我們這樣的討論可能持續時間比較長，會影響到我們的生產力。

三、得到的經驗和教訓

1.應該及時的進行角色輪換

我們沒有進行角色輪換，一直是一個人做Driver,另外一個人做Navigator ，這樣有時會因為過度思考，而導致觀察力和判斷力出現偏差。

建議以後進行結對程式設計每半天進行一次角色輪換。

2.結對程式設計需要相互尊重(respect)

工作及時得到同伴的肯定，自信心和成就感會增強，覺得工作很愉快，很願意很partner一起工作，這樣就會提高生產率。

3.不要在ACTION裡寫太多邏輯

這次結對程式設計採用了單元測試，在測試ACTION的邏輯時，發現因為在ACTION裡寫了太多邏輯，單元測試根目錄本無法實施，如果我們將ACTION裡的邏輯都移到邏輯類裡，那樣進行單元測試就方便多了。

4.不要用netMetting

我們在結對程式設計之初很喜歡用這種該方式進行相互監督，後來發現這種方式很容易造成注意力不集中，還是應該兩個人都並排坐在一台電腦前，面對同一個顯示器，使用同一個鍵盤，同一個滑鼠一起工作。

後記：這篇文章是我很多年前剛工作的的時候，做的內部分享，一直保留著，很多東西寫出來才能成為自己的東西。建議那些剛工作的朋友，養成總結的習慣，寫寫周總結，月總結，這樣不斷複盤，成長速度會很快。

稿源：程式師

會影響到我們的效率。