多維角度聊聊結對編程

在敏捷軟件開發的各種實踐中，結對編程（Pair Programming，下文簡稱Pair）是特別有爭議的。Pair有一個特點，那就是還沒有進行過任何Pair實踐前，你很可能對它已經有了“喜歡” 或者是“討厭”的印象。如果有人問你，你喜歡持續集成嗎？你多半會回答：不是很肯定，需要試試看。但如果有人問你，你喜歡Pair嗎？我猜你會馬上給予明 確的肯定或否定的回答。喜歡它的人會覺得好處多多而成本低低，不喜歡它的人會覺得討厭得難以想象。喜歡與不喜歡都可以形成強大的陣營，兩邊都不乏重量級的 高手。Pair的優點說起來都很明顯，比如：快速反饋，更好的設計，甚至更高的效率等等。但據我了解，不喜歡Pair的人基本上都承認Pair有優點，只 是他們通常會提出反對意見，比如：Pair要求兩個人協調一致，每個人的作息時間需要同步，如果一個人請假，那另一個人怎么辦？等待就太浪費時間了，如果 自己一個人做那就不是Pair了；或者也有很多人感覺到Pair的時候特別累，不像一個人工作那樣自主，寫一小時程序，上十分鐘微博，兩個人同一臺電腦工 作自由就小多了。

我所在的公司是Pair的實踐者，對于喜歡Pair或者不喜歡Pair的各種原因和心態我都有切身的體 會。在實踐中，我們并沒有完全一成不變地照搬Kent Beck在《Extreme Programming Explained》書中所定義的Pair模式（Driver Observer模式）。因為，Pair畢竟是一種實踐方法，可以供我們在軟件開發中參考，而不必像對待科學理論一樣教條。另外，我認為要讓這種實踐方法 發揮它的威力，消除人們心中的討厭甚至是恐懼情緒是首先要解決的問題，甚至我們可以為此修改一些Pair的傳統做法。下面我先來大致描述一下我們的實踐模 式（Owner Supporter模式）：

<階段1-Pair形成>

Team 在接到一個大的Story后經過討論并分解任務形成一個個粒度適中的Task。Task的粒度一般在幾小時到一兩天這種級別，涉及的代碼規模大約是幾行到 幾個類/函數。每一個Task，都有一個Owner作為責任人，這是和傳統單兵開發模式相同的。不過，Owner的產生一般不是由ScrumMaster 來分配指定，而是Team成員自發地去協商選擇適當的任務。Owner拿到Task以后會從Team中找一個Supporter，形成Pair。這也是一 個自發協商過程，沒有強制指定，也沒有固定的搭檔，這樣形成的Pair一般會是配合最默契也最適合相應Task的。

<階段2-初始討論>

Pair 形成以后， 一般是由Owner先分析需求，設計測試，并初步分析思考得出初步的設計思路。這時，Supporter可以暫時先不了解需求。然后Owner邀請 Supporter一起，向Supporter介紹需求和自己的設計思路。Supporter這時需要幫助Owner理解需求，設計測試，對設計方案提出 反饋意見，或者提出新的設計。討論的理想結果是兩人達成一致形成最終的設計方案，如果兩人分歧嚴重不能達成一致則需要更多的人參與，比如：可以舉行一個小 型的技術討論會議把討論擴大到整個Team。

<階段3-具體實現>

這一階段是根據討論得出的設計方案開始編程實現。在經典Pair Programming中，兩個人是在同一臺電腦前一起工作，并不時地交換；但我們的實踐發現這一點是特別容易讓人疲倦，感覺不自在，從而抵觸Pair的 最大因素。所以，我們在實踐過程中，除了少數情況，基本上沒有采用全程Pair工作，而是由Owner一個人完成。當然，如果Owner遇到了一些設計中 考慮不完善的地方，他可以隨時再和Supporter討論。

<階段4-Review>

具 體實現完成以后，Owner又會邀請Supporter來review自己的工作。這個過程一般是借助版本控制工具對比代碼改動，Supporter從實 現的角度來審查實現是否符合設計，有沒有可以直接觀察到的bug和潛在的問題。如果發現問題并討論確認，Owner再做相應的改動，再Review。最終 Supporter不能review出問題了，Owner提交代碼。

<階段5-維護>

雖 然經過了討論和review， 但在后續的測試或者上線后仍然會陸續發現問題，這時就涉及到維護工作。維護工作依然是由Owner牽頭，分析log，看代碼，重現，修正；但 是，Owner也可以隨時邀請Supporter參與分析討論，至少在Owner準備修改原先的代碼時應該要告訴Supporter“原先我們某個地方沒 有考慮周全，有什么什么問題，我打算怎么怎么改動”。這個過程好像又回到了階段2，然后階段3，階段4 ... 開發中還有一種可能是，原先的Supporter或Owner已經不在Team內了，這時就需要加入一個新人形成Pair，有經驗的人應該向自己的新搭檔 介紹Task的相關背景。當然，還很有可能碰到根本沒有熟悉該模塊的人了，這時就必須形成一個新的Pair，把維護作為一項新Task。

上面基本上就是我們的Pair實踐模式了。這種模式基本上還是保留了大部分經典Pair模式的要點，主要的區別在于：

1. 把Pair的形成納入Scrum框架的任務劃分過程。Scrum通常會在Sprint的計劃會議中將大的User Story拆分成許多小的Task，每個Task一般對應幾小時到一兩天的工作量。Task列表出來以后，Team自發協商每個Task形成一個 Pair，整個過程一般沒有管理者的直接干預。Story的背景需要Team中的每個人都了解，Task的細節由Pair負責。Pair的效果通常也依賴 于Task的合理劃分。

2. 避免全程Pair。因為，全程Pair在實踐和心理上會遇到很多問題，比如：時間同步問題，并行工作問題，不自在感問題。避免全程Pair可以使得 Owner和Supporter的時間安排更加靈活，增加并行性，減少不自在感。大部分不喜歡Pair的人基本上都是尤其不喜歡全程Pair，所以這項改 動對于吸引更多的人采用Pair具有重要的意義。

3. 區分Owner和Supporter的職責。經典Pair模式中Driver和Observer角色是隨時交換的，也就是說對于一個Task來講兩個人的 職責是相同的，這樣可以減小每一個人的壓力，但又容易造成缺乏責任感。Owner Supporter模式是單兵模式和經典Pair模式之間的一種妥協，試圖在責任和壓力之間找到一種平衡。Owner是驅動整個過程的主導，并且是主要的 具體實現者；Supporter以輔助為主，在討論和review的時候可以站在不同的角度幫助Owner。Supporter并非沒有責任，熟悉Task的所有細節是Supporter的責任。當Owner由于請假或忙于其他事物時，Supporter應該立即可以代替Owner處理Task的實現或維護。如果Supporter做不到完全的backup，這就是Supporter的失職，在整個Team和領導的心中應該有這樣的認識。

最后，除了顯而易見的“引入反饋，提高質量”等很“官方”的優點外，我從管理者和開發人員的角度分別總結一下Owner Supporter模式的“不為人知”卻真正很有價值的優點。

管理者角度：

1. 應對人員變動：每個模塊至少兩個人熟悉，這樣在有人請假的時候都有backup，不會造成嚴重的耽誤工作進度。如果有人要離職，交接工作通常也會非常輕 松，幾乎沒有什么需要特別交接的。很多項目都缺乏文檔，只有實現的人知道怎么回事，而即使有文檔也總有不清楚的地方，所以留住熟悉的人就是留下了活文檔。

2. 增加對質量的信心：相比單兵作戰模式，即使是不懂技術的管理者，Pair也可以自然地增加他們對于軟件質量的信心，畢竟“三個臭皮匠頂個諸葛亮”。另外， 需要特別提到的是安全性問題。我曾經聽說過一個電信計費項目，一個開發人員故意留了一個漏洞，把錢自動打入自己的銀行卡，最終為公司帶來了麻煩。如果采用 Pair方式，這種情況就不那么容易發生。

3. 增加反饋：對于同一個事物，不同的人也會有不同的看法，這是很正常的現象。比如，在對問題進行估計時一個人樂觀，一個人悲觀，這時管理層可以同時參考他們的意見，對問題掌握得更加全面。

4. 代替培訓：相比傳統課程或講座式培訓，Pair能讓新員工更快地適應項目。Pair方法也和一些公司采用的導師制有明顯的區別。導師制更強調師傅帶徒弟， 而Pair則不然。在實踐中，我們更鼓勵基礎比較好的新員工多做Owner，老員工作為Supporter支持；只對基礎比較差的新員工先從 Supporter做起，然后逐步過渡到Owner。這樣做是因為新員工一般積極性比較高，適合承擔更多的具體工作，而老員工則應該避免重復勞動，而是以 輔助和指導為主。另外，新員工也可能帶來一些新的思想、方法和技能，這些反而是老員工應該學習的。

開發人員角度：

1. 分擔壓力，增加默契：Task依然具有明確的責任人，但Supporter可以分擔Owner的壓力，即使是Team內的技術高手有一個人做backup也是有益的。有人討論有人支持更容易達到良好的工作效果，而大家相互Support也可以讓團隊更加默契。

2. 消除經典Pair的不自在感： Owner Supporter模式與經典Pair的Driver Observer模式相比更少存在不自在感，因為整個過程是Owner主導的，他有更多的自由安排什么時候討論，什么時候獨立工作。

3. 分享知識和技能：在Pair的過程中Owner和Supporter會自然地相互傳播和分享知識和技能，有助于學習提高。

4. 培養組織能力和表達能力： Owner相當于一個微型團隊的leader，在Pair過程中可以鍛煉組織能力和表達能力。這個過程可以讓一些不善于交流和組織的技術人員逐漸改善交流和組織能力。

Owner Supporter模式在我們的實踐中收到了良好的效果，而且成本很低，值得推薦！