pair programing是所有XP實踐中爭議最大的一個，但竊以為確實XP實施的關鍵關鍵實踐之一，甚至于，我認為很多XP實施的失敗都是由于沒有采用pair programming而造成的。
要了解pair為什么重要，就要了解pair的目的在何。當然了，大多數人都知道pair的重點在于知識傳遞，知識共享，持續走查，降低代碼缺陷等等等等。這些都是pair的優點，不過最重要的一點卻常常被忽略——pair programing的最直接而又最根本的目的之一在于simple design。



上圖是著名的Ron Jefferies Model，可以看到XP最佳實踐被劃分成了一個一個的圓圈，而pair, TDD, refactor和simple design位于中心。這并不是說這四個實踐就是xp的核心。jefferies model每一圈代表了xp實踐過程中的不同關注點，最中心的是dev視角，其次是team視角，最外層是交付／管理視角。每圈上的最佳時間多少都有些緊耦合，放開其他的不講，我們專門說說dev圈，pair programing, tdd, refactor和simple design。

這四個實踐里只有simple design最虛也最重要。有一個問題已經被問過無數次了，“到底多simple的design才叫simple”。我對此也有一個近乎刻板的回答：team里所有人員都能夠理解的design就是simple的。一旦立了標準，這四個實踐的主從關系就一下子清晰起來——simple design是這四個實踐的核心，其他三個實踐都是它服務的。

首先做出一個設計，最簡單的判斷標準就是是否可測，一個不可測的設計基本上可以認為無法實現，于是TDD即是simple design的質量保證又是simple design的直覺驗證。

refactor是為了得到好的代碼，那么什么是好的代碼？simple design!!!這里有人不同意了，有人說只是要易于修改和擴展，可是擴展和修改也要別人看得懂才行啊...simple design是起碼的要求嘛。實際上，XP中的refactor就是朝著simple design的方向重構過去的，也就是朝著所有人都能理解的代碼refactor過去的。插一句題外話，為啥說好的架構的不是設計出來的呢？因為好的架構至少應該是simple design的，而simple的概念有和人員相關...所以當你極盡能事show off你的pattern知識之后，得到復雜設計根本就不可能是好的架構。時刻緊記，架構是妥協啊...

最后，pair programming是simple design的實際檢驗！！！因為即便是最復雜的設計，只要是你自己想出來的，你都覺得它簡單無比，里面充滿了直白且顯而易見的理由。可惜不幸的是，我們要的簡單，是對team里所有人的簡單。如果你的pair不能理解你的設計，那么說明你的設計復雜了;如果你們兩個人懂，但是swith pair的時候，換過來的人不懂，說明你的設計復雜了。pair programming(以及他那容易讓人忽略的子實踐switching pair)就是檢驗simple design的過程。pair programing + refactor就是時刻保證simple design防止過渡設計反攻倒算的過程。pair programming + refactor + tdd就是團結在以Deming同學built quality in的質量大旗下，堅定地與過渡設計做斗爭的過程。據我觀察，至沒有使用pair programming的團隊中，少一半simple design成了口號，而這一半中，至少又有一半最終放棄了xp放棄了敏捷（俺以前帶過的團隊就有這樣的...默哀一下）。深刻的教訓啊，我們來高呼一下："pair programming是檢驗simple design的唯一標準！"。

最后說一下pair programming經濟學，過多的假設我就不講了。單說一點，有哪一位上班的8小時從來不上msn/yahoo/qq等im?有哪一位上班從來不上論壇/不回貼/不發郵件?以我pair的經驗來看，pair programming的過程中，兩個人幾乎不會用im，幾乎不會逛論壇。你不好意思呀，畢竟不是你一個人的機器，畢竟是兩個人的時間，畢竟你也不愿意給同事一種懶散的印象吧？收回的這么浪費的時間，至少頂得過另外一個人的工作時間了吧？