Pair Programming (結對程式設計)

我的第一次Pair（Pair Programming的簡稱，即結對程式設計。後面都是用Pair代替）是在TW公司面試進行的。那次，他們來自英國的專案經理面試我，和我一起進行Pair。他問我以前是否Pair過，我說：“沒有，這是我第一次Pair”。隨即他就告訴我：“It’s very fun.（它非常有趣）。”

就這樣，開始了我的第一次Pair，也是加入TW最重要的一輪面試。其實，剛開始很不習慣，我那可憐的英語口語，陌生的測試優先開發（TDD Test Driven Development  一種軟體開發方式，先寫單元測試代碼，再寫業務代碼。我以前也寫過很多單元測試，但從沒有測試優先）。當我看到需求文檔時，大腦幾乎是一片空白，不知從何處下手。

但面試總不能就這樣放棄吧。我又仔細看了一遍文檔，嘗試著寫了幾段業務代碼。做在我旁邊的Andy搖了搖頭，從我手裡拿了鍵盤。他說應該這樣做，先寫測試代碼。於是他一邊和我解釋業務需求，一邊寫測試代碼。並提醒我，如何去對一個複雜的功能進行分解，並且小步伐的前進。

在Andy的引導下，我慢慢的進入了角色。充分理解業務之後，也就清楚了該如何寫業務代碼。我從Andy那裡要了鍵盤，又寫了幾段代碼。然後運行單元測試，綠色狀態，測試成功。Andy微笑的向我豎起了大拇指。

受到鼓勵的我，這是已完全放鬆進入狀態。我們又試著完成了幾個功能。這時，我們已經不只覺的渡過了2.5個小時。Pair確實是一件非常有趣的事。

進入TW公司之後，發現在大家不僅Pair編程，還Pair研究技術，Pair撰寫文章，Pair翻譯，等等。只要是Pair能完成的工作，我們就不一個人完成。甚至在生活中也出現了很多Pair的影子。在我們的西安Office裡流傳這樣一句話：“我們Pair做任何一件事情”。兩個人Pair，可以一起一起分享工作樂趣，一起承擔工作壓力。

這些天的Pair生活，讓我深深體會到了Pair的優點。

一、Pair 可以最大化的提高工作效率。 軟體開發並不只是程式員堆砌代碼的過程，它更多的是一個創新的過程，是一個發現問題、分析問題、解決問題的過程。一個人編程時，往往有了一絲零碎的想法就開始編寫代碼。寫完代碼之後，忽然發現這個方案行不通，只好廢棄這些代碼，重新開始新的想法。當一個人在遇到疑難問題時，很容易走入“死角”。而Pair則不同，一個人有了想法，首先要表達出來，讓自己的同伴理解，經過深刻的討論，一致認可之後才開始編寫代碼。一個人編寫代碼，另一個則在旁邊思考，會為下一步的工作提出建設性的意見。發現了問題可以及時的指正。大大的提高了代碼品質。

一個人一天有效工作時間不超過3－4個小時。兩個人一起Pair。一個人編寫代碼，另一個人則從設計的角度思考下一步的工作，有了想法之後，互相討論，再互換角色。在開發過程中，設計思考和編碼實現不停的進行交換，保持了良好的開發節奏。同時可以互相督促，使彼此更加認真的工作。遇到問題和壓力時，可以一起面對，互相鼓勵。可以一起分享解決問題的成就和樂趣。

二、Pair 是知識傳播的最好途徑。 很多軟體公司都建立有自己的知識庫，有的還建立自己的培訓部門，甚至高薪聘請一些專家做技術培訓。但發現效果並不理想。培訓之後，開發人員面臨實際的項目，還是一片茫然。而與有經驗的同事一起Pair則是在實際項目中學習，具有非常強的針對性。你學到的不僅是一些技術和技巧，更多是他們思考問題方式、解決問題的方法。和各種不同經驗的同事一起Pair，你的經驗和能力可以得到快速的提高。

在TW公司，如果你要加入一個項目，完全不用擔心它使用的技術和涉及的業務。只要你有一定的基礎，和有經驗的同事一起Pair能讓你很快熟悉和掌握它們。

三、Pair 可以打造出最佳的合作團隊。 團隊是有組織有計劃的，合理有效地利用各種資源，進行最佳的組合。Pair並不是一對固定的夥伴，我們鼓勵在團隊中經常交換Pair夥伴。這時我們發現，項目不再是一個人的事情，也不是兩個人的事情，而是整個團隊的事情。

通過Pair，大家可以在最短的時間內完成磨合。Pair很好的促進了團隊的溝通交流，經常一起合作Pair的夥伴，彼此瞭解、熟悉，很多都是工作和生活上的好友。在這樣的團隊裡，大家很樂意互相協助，一起分享知識，分享快樂。

  在聽過我們一番熱情洋溢的闡述之後，某些專案管理者會點頭並且認可Pair帶來的力量。但，我們也聽到了一些拒絕Pair的聲音。下面是我們聽到的拒絕Pair的最主要的理由，當然也包括了我們的辯解。

一、 Pair 浪費資源。 以前是一個人完成的工作，而現在卻是由兩個人一起完成。一個人在寫程式，而另一個卻在旁邊觀望。為開發人員支付報酬的老闆是多麼心疼那些白花花的銀子。

  可是，作為老闆的你可曾做過統計過，每天加班工作12小時，滿臉疲憊的開發人員到底為你創造了多少的價值？在這漫長的12小時中，能生產力的時間又能有多少呢？一個開發人員每天編寫幾百行的代碼，可是真正具有實效性的代碼又有多少呢？

  軟體的本質就是很難用一種標準去衡量它的進度和實效性。開發人員能力的高與低、經驗的多與少、工作的主動與被動，對軟體開發的成本有非常大的影響。前期糟糕的代碼，在後期修正，是需要付出幾倍甚至更多的代價。在軟體的行業裡，人月和程式碼永遠是神話。

在1999年，猶他州立大學（University of Utah）做了一項實驗。.兩組學生，一組獨自工作（一共13人），一組Pair（一共28人，即14對）。他們完成相同的任務（由助教預先設計和開發了測試案例）。

下面的表格（圖－1）是完成相同的四個程式，獨自工作和Pair工作使測試案例成功通過的百分比。

（圖－1）

下面的柱狀圖（圖－2）則是完成相同的程式，兩組所花費的時間比。雖然Pair的學生在剛開始的階段比獨自工作的學生花在同樣任務的時間較多，但很快Pair的學生的時間開始大幅度的下降。而獨立工作的學生需要花費比Pairs更多的時間來達到接近的代碼品質。

（圖－2）

而且，在具體項目中。Pair會帶來比上面結果更高的價值。一、在實際開發中，如果錯誤越多，就要花費越多的時間去修複它。在我們的實驗中，沒有統計修複錯誤所花費的時間。二、從圖－1可以看出，Pair在產生高品質代碼時，也即意味著對需求的準確理解。個人團隊對需求理解偏差比較大，後期也要花費更大的代價來糾正。三、從圖－2可以看到，Pair的團隊開發能力提高很快，這是潛在的價值。

在比較實驗之後的問卷調查之後發現：

ü      Pair能用較少的時間生產更高品質的代碼。

ü      Pair的學生們認為自己比一個人的時候更勤奮和更聰明的工作，因為不想讓自己的partner失望。

ü      Pair的學生認為自己比一個人的時候更專著,緊湊和由紀律的工作，而且是持續的。而獨立工作的學生也可以專著和緊湊的工作，但往往不持續。

ü      在緊張時間安排和繁重的工作壓力下，獨自工作的學生很容易蛻變為沒有紀律的程式員。

  同時，在TW這樣的公司，每個開發人員都是能夠獨擋一面。TW的開發人員，在一般的軟體公司都是類似專案經理或架構師的角色。你可以想象公司肯定要為他們提供不翡的待遇。可是，他們卻Pair做任何一件事情，也從不認為自己是在浪費資源。相反，TW從實踐中得出：Pair能夠充分的利用每個開發人員，讓他們發揮最大的價值。

  二、人手不夠。 也許，在你的公司，昨天又有一個老員工遞交了辭職申請。老闆看著一張張新的面孔，很無奈的搖了搖頭。招聘員工並不困難。但如何讓新員工快速進入角色，掌握公司的技術和業務呢？

    人員的流動一直是讓很多軟體公司非常困擾的問題。特別是老員工的離去，也就意味著公司多年的技術和業務積累的流失。

而在Pair工作的團隊中，幾乎不用擔心這個問題。Pair可以快速的進行知識傳遞，通過Pair和Pair夥伴的交換，知識不再是掌握在一個人的手中，而是整個團隊一起共用。

在TW內部，工作的調整和變換是非常頻繁的。但很少會對項目造成影響。相反，這樣的變換卻加快了知識的傳遞。

 

三、開發人員不能很好的合作，Pair 對開發人員要求太高。 真的要求很高嗎？看看求職簡曆，不是每個開發人員都口口聲稱自己具有很好的團隊合作精神嗎？如果你不能很好的和別人Pair，團隊精神又從何談起呢？

那任何兩個人都可以搭配進行Pair嗎？

不，Pair對開發人員是有要求的。它要求開發人員樂意和別人溝通、合作，要求開發人員能夠彼此尊重，願意和別人分享自己的知識。這不正是我們一直倡導的團隊合作精神嘛！

Pair的搭配是一個有趣的問題。有人說，最好的搭配就是兩個人能力相當。其實不然，Pair應該是一種多樣的變換組合。在Pair的團隊中，經驗豐富的開發人員有責任帶領新人，傳知授道解惑，同時可以享受傳道的樂趣。新人，更應主動找有經驗的夥伴Pair，快速學習提高自己。Pair的核心就是溝通，只要兩個人能很好的進行溝通，那麼他們就可以很好的搭配。

關於Pair的實施，其實並不困難。我們需要的只是經驗，當然經驗也只會來源於實踐。