</h1>
<div class="clear"></div>
<div class="postBody">
最先的結對編程 (Pair Programming)
結對編程隨着敏捷開發思想的興起而廣爲人知, 然而這種實踐早已有之。 在 1987年, Intuit 公司 （當時只是一個剛剛創業的我的財務管理軟件公司）向顧客宣佈在 4 月份提供新版本的軟件 (4月15日是美國報稅的截止日期)。 但到了 3 月份的時候, 公司僅有的兩個技術人員發現項目仍是大大落後於預期, 因而這兩人在 3 月的最後一個週末開展了瘋狂的，不得已的結對編程活動:程序員
來源: Amazon.com: Inside Intuit: How the Makers of Quicken Beat Microsoft and Revolutionized an Entire Industry (9781591391364): Suzanne Taylor, Kathy Schroeder, John Doerr: Books 算法
有人要問，既然代碼複審能發現這麼多問題，有這麼好的效果，若是咱們每時每刻都處在代碼複審的狀態，那不是很好麼？事實上，極限編程（Extreme Programming - XP）正是這一思想的體現——爲何不把一些卓有成效的開發方法用到極致（Extreme）? 結對編程就是一個例子。app
在結對編程模式下，一對程序員肩並肩地、平等地、互補地進行開發工做。兩個程序員並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤，同一個鼠標一塊兒工做。他們一塊兒分析，一塊兒設計，一塊兒寫測試用例，一塊兒編碼，一塊兒單元測試，一塊兒集成測試，一塊兒寫文檔等。ide
結對編程不是程序開發者獨到的發明，在現實生活中，也存在着相似的搭檔關係（Partnership）：函數
越野賽車（駕駛，領航員）工具
駕駛飛機（駕駛，副駕駛）
戰鬥機的編組（長機，僚機）
提示：這些任務都有共同點：在高速度中完成任務，任務有較高的技術要求，任務失敗的代價很高。
結對編程中的角色
結對編程中有兩個角色：
（a）駕駛員（Driver）是控制鍵盤輸入的人。
（b）領航員（Navigator）起到領航、提醒的做用。
這兩個角色是能夠互換的。和現實生活中的例子相似，一我的負責具體的執行（駕駛，用鍵盤編輯程序等），另外一人負責導航、檢查、掩護等。
同窗們雜曰——
1）編程歷來就是一我的的活動。學校裏這麼教的，咱們一直以來也是這麼作的。兩我的原本能夠去作兩個模塊，如今一個模塊兩我的寫是否是一種浪費（這但是兩份工資哦）？
2）我習慣一我的寫程序，不喜歡被人盯着工做，這樣我不自在，沒法工做。
3）身旁的這個傢伙總是問問題，他/她不會看書麼？我都沒法專心工做了。
4）會不會出現，「我只領航，不用敲鍵盤，多爽……」的狀況？
5）有些公司規定全部的任務都要結對編程, 結果你們都走形式, 濫竽充數的人也在結對編程的過程當中得過且過
……
爲何要結對編程？
每人在各自獨立設計、實現軟件的過程當中難免要犯這樣那樣的錯誤。在結對編程中，由於有隨時的複審和交流，程序各方面的質量取決於一對程序員中各方面水平較高的那一位。這樣，程序中的錯誤就會少得多，程序的初始質量會高不少，這樣會省下不少之後修改、測試的時間。具體地說，結對編程有以下的好處：
（1）在開發層次，結對編程能提供更好的設計質量和代碼質量，兩人合做能有更強的解決問題的能力。
（2）對開發人員自身來講，結對工做能帶來更多的信心，高質量的產出能帶來更高的知足感。
（3）在心理上, 當有另外一我的在你身邊和你緊密配合, 作一樣一件事情的時候, 你很差意思開小差, 也很差意思糊弄。
（4）在企業管理層次上，結對能更有效地交流，相互學習和傳遞經驗，能更好地處理人員流動。由於一我的的知識已經被其餘人共享。
總之，若是運用得當，結對編程能獲得更高的投入產出比（Return of Investment）。
不間斷地複審
結對編程讓兩我的所寫的代碼不斷地處於「複審」的過程，正如前所述，複審是不斷地審覈，提升設計和編碼質量的過程，結對編程讓複審隨時隨地發生，這樣才能及時地發現問題和解決問題，避免把問題拖到後面的階段。
開發中的複審主要包括：設計複審、代碼複審、測試計劃複審、文檔複審。
這些複審能夠在夥伴之間進行，也能夠在團隊內部進行。結對編程和傳統開發過程的複審有什麼區別呢？
（1）傳統意義上的夥伴複審，即程序員之間的互相複審，有如下的問題：
a. 複審人缺少對程序的深刻了解，下降了複審的效果；
b. 不能持久、定時地進行復審；
c. 對需求和設計的不瞭解致使沒法實現全面有效的複審。
（2）團隊複審是指多於兩人的團隊就某一程序實體進行的複審，團隊複審的缺點在於：
a. 何時開會作複審？不可能一個團隊每天開會。要找到一個全部人都能出席的時間，並不容易；
b. 牽涉的人員衆多，理解程度不一，複審的速度和效果不能獲得有效的平衡——太快則有人不懂，太慢則浪費許多人的時間；
c. 正是因爲成本問題，沒法對全部的設計和代碼進行深刻的複審；
d. 因爲人員衆多，有面子問題。
在結對編程中，任何一段代碼都至少被兩雙眼睛看過，兩個腦殼思考過。代碼被不斷地複審，這樣能夠避免牛仔式的編程。同時，結對編程避免了「個人代碼」仍是「他的代碼」的問題，使得代碼的責任不屬於某我的，而是屬於兩我的，進而屬於整個團隊，這樣可以幫助創建集體擁有代碼的意識，在必定程度上避免了我的英雄主義。
結對編程的過程也是一個互相督促的過程，每一個人的一舉一動都在別人的視線以內，全部的想法都要受到對方的評價。因爲這種督促的壓力，使得程序員更認真地工做。結對編程「迫使」程序員必須頻繁地交流，並且要提升本身的技術能力以避免被別人小看。
可是要注意，每一個人天天的高效率工做時段不超過3~4個小時。結對編程中駕駛員和領航員的互換可讓程序員輪流工做，從而避免出現過分思考而致使觀察力和判斷力降低。
什麼樣的人適合結對編程？
Extreme Programming對實施的程序員提出了更高的要求。這種要求不是技術水平，也不是學歷水平或工做經驗。這種要求是對一我的的心智、道德修養的更高要求。結對編程中，編碼再也不是私人的工做，而是一種公開的「表演」。程序員的代碼、工做方式、技術水平都變得公開和透明，這也許是有些同窗不喜歡這一方式的緣由。
如何結對編程？
（1）駕駛員：寫設計文檔，進行編碼和單元測試等XP開發流程。
（2）領航員：審閱駕駛員的文檔、駕駛員對編碼等開發流程的執行；考慮單元測試的覆蓋程度；是否須要和如何重構；幫助駕駛員解決具體的技術問題。
（3）駕駛員和領航員不斷輪換角色，不宜連續工做超過一小時。領航員要控制時間。
（4）主動參與。任何一個任務都首先是兩我的的責任，也是全部人的責任。沒有「個人代碼」、「你的代碼」或「她的代碼」，只有「咱們的代碼」。
（5）只有水平上的差距，沒有級別上的差別。儘管可能你們的級別資歷不一樣，但無論在分析、設計或編碼上，雙方都擁有平等的決策權利。
結對編程是個漸進的過程——
有效率的結對編程不是一天就能作到的。結對編程是一個相互學習、相互磨合的漸進過程。開發人員須要時間來適應這種新的開發模式。剛開始的結對編程極可能不比單獨開發效率更高。可是在度過了學習階段後，結對編程小組的開發質量、開發時間一般比兩人單獨開發有明顯的改善。
要避免的誤區——
1) 不分狀況強迫每一個任務都用結對編程的方式, 或者執拗地遵照一些教條 (例如 "結對的成員必須水平至關..." 等等)
2) 沒有提供足夠的支持就匆忙上馬結對編程 - 工做環境, 硬件, 對結果的指望都要準備好。
3) 在具體做法上加入過多限制或要求 - 應該讓兩位程序員本身決定具體的方式。
不適合結對編程的狀況——
並非全部的項目都適合結對編程，下面是一些不適合使用的例子。
1）處於探索階段的項目，須要深刻地研究，在這種狀況下，一我的長時間的獨立鑽研是有必要的。
2）在作後期維護的時候，若是維護的技術含量不高，只須要作有效的複審便可，沒必要拘泥於形式，硬拉一我的來結對唱二人轉。
3）若是驗證測試須要運行很長時間，那麼兩我的在那裏等待結果是有點浪費時間。
4）若是團隊的人員要在多個項目中工做，不能充分保證足夠的結對編程時間，那麼成員要常常處於等待的狀態，反而影響效率。
5）關鍵是如何最大限度地發揮「領航員」的做用，若是用處不大，也就無需結對。
推而廣之，所謂極限編程，就是把一些認爲重要和有效的作法發揮到極致，如表11-1所示，在這層意義上，「極限編程」應該叫「極致編程」。
表11-1 極致編程
| 若是…… |
發揮到極致就變成…… |
| 瞭解顧客的需求很重要 |
每時每刻都有客戶在身邊，時時瞭解需求 |
| 測試/單元測試能幫助提升質量 |
那就先寫單元測試，從測試開始寫程序——TDD |
| 代碼複審能夠找到錯誤 |
從一開始就處於「複審」狀態——結對編程 |
| 計劃沒有變化快 |
那就別作詳細的設計，作頻繁的增量開發，重構和頻繁地發佈 |
| 其餘好方法…… |
發揮到極限的作法…… |
下面是 <現代軟件工程> 的同窗們親身體驗告終對編程以後的一些感想:
(link)
第一次體會到結對帶來的效率：
那是project到了比較關鍵的創造階段，整整一天，咱們倆椅子靠椅子的坐在電腦前，一邊討論通常coding，那次才真正的體會到結對真的可以帶來效率。一成天的coding是容易走神的事，還好有pair在旁邊指導，老是不斷在我敲某某變量以前提早告訴我成員變量的名字，數據修改時幫忙檢查是否有漏掉的，變量和函數定義的時候一塊兒爲其取名字，感受有點眼花了，就換了個角色，我也開始對他「指指點點」了，一我的coding，一我的review，確實能減小一些沒必要要的錯誤，減小一些漏洞，算法實現後一塊兒作些簡單的測試，看到bug了再一塊兒分析，我能明顯的感受到與之前的我的編程不同，咱們能比較快的找到bug初始點，並能提出比較的修改方法。特別是當看到功能進一步實現時，內心確實挺happy，更重要的這份感覺有同伴與你一塊兒分享。
(link)
之前以爲結對編程的效率不高，由於只有一我的可以在敲代碼，後來發現，事實不是這樣的。兩我的在一塊兒的時候，一我的敲代碼，另外一我的可以及時發現錯誤，出現什麼問題也可以一塊兒討論，其實效率更高。兩我的一塊兒的時候可以更加全身心的投入，並且互相都可以學到不少東西。總之經過此次結對編程，感受收益匪淺。
(Link)
因而咱們進行了項目中最關鍵的一次Pair Programming，咱們利用編譯課上機時間，在機房裏Pair完成了整個項目的類的設計與程序結構的設計。咱們一塊兒分析出類，而後找屬性，寫方法頭，開始是WG用鍵盤，後來我用。一個明顯的好處是，寫完一條本身不肯定的語句，立刻能夠跟Pair一塊兒縷一縷思路。一下午下來，感受甚爲清爽，由於終於清楚這個項目的作法了。
另外，除了兩人坐在一塊兒，軟件工具也能幫助更好地合做， 請看這個 Live Share 插件：https://visualstudio.microsoft.com/services/live-share/
兩人合做
軟件開發的過程看似一個個程序員在孤獨地寫代碼, 其實一個成功的軟件團隊, 成功的企業須要不少合做, 從歷史上看, 咱們能夠發現不少成功的企業都是兩我的合夥開創的， 下面是一些例子:
(惠普公司的兩位創始人在車庫工做)
(Unix 和 C 語音的兩位創始人)
(蘋果公司的兩位創始人)
(微軟公司的兩位創始人)
(推進PC 發展的電子表格程序 - VisicALC - 的兩位創始人 Dan & Bob)
(Yahoo 的兩位創始人 David & Jerry)
(Google 的兩位創始人)
(Facebook 的兩位創始人 Mark and Eduardo [電影畫面])
…
說到合做, 有些孤獨的高手沒人可合做, 無聊得會讓左右手互搏, 可是通常人仍是須要不少人來幫忙作事情, 兩人一對一的合做是其餘合做的基礎。除了兩人一見如故, 永遠是蜜月期的那種個例, 大部分人的夥伴關係也是有一個不平坦的發展過程, 下面咱們來看看兩人合做有什麼階段:
兩人合做的不一樣階段（舞蹈版）
移山公司的同事們中午吃飯時，你們關心起阿亨的婚姻大事來，紛紛給他支招，問他們如今到了什麼階段，是否拜見過對方父母，是否談婚論嫁等。忽然有人問了這麼一句：「大家吵過架了麼？」阿亨一愣，想了想，說：「沒有。」雜曰：「那還早得很，還有很長的路要走呢！」
下午開會的時候，阿超說，人不可能沒有矛盾，兩我的連架都沒吵過，說明兩我的之間仍是有距離。談戀愛，兩人合做項目，都有相似的階段，你們在學校裏跳舞有沒有舞伴？下面咱們以舞伴爲例，描述一下各個階段。
以跳舞爲例，剛認識，拘謹而彬彬有禮。
這一階段的現象：兩人剛剛互相認識，這時你們都有禮貌，通常交流很多，每一個人都想獲得對方的接納，試圖避免衝突和容易引發挑戰的觀點。對即將進行的舞蹈，有不一樣的指望值。
2．磨合階段（Storming）
開始跳舞，開始踩腳。接觸以後，才感到手足無措，眼睛不知往哪裏看，才能感到對方原來舞步是這樣的……這樣的笨拙。這時，會出現以下對話：
——哦，對不起，我又踩了你的腳。
——噢！您揪着個人肉了！
——哦，我是要你向右轉！
——你這叫跳舞麼，簡直就是牽驢拉磨！
……
——對不起，我昨晚對你態度很差，我們今晚還去跳舞麼？
跳舞逐漸和諧、合拍，團隊成員就不少事情取得了一致。一些成文或不成文的規則逐步創建起來了。男方輕輕的一個手勢，女方就知道如何旋轉。
跳舞二人合而爲一，爲藝術而舞蹈（你們發出了唏噓嚮往之聲）。
並非全部的合做都能達到這一階段，Storming太多後，咱們還可能進入「解體階段」。
散夥，各走各的獨木橋，回宿舍抱着板凳跳舞，或者另找舞伴。
同窗們嘗試結對編程一個星期後，阿超詢問荔荔感想如何，荔荔支吾半晌說，兩我的討論，是否是比誰的嗓門大？我和九條討論的時候，他的嗓門愈來愈大，我只好贊成他的說法了。
阿超說，兩人在一塊兒合做，天然會出現不一樣意見，每一個人都有本身的想法，在兩我的平等合做的狀況下，不存在領導與被領導的關係，如何能說服對方？要聽對方的話語和觀察對方的肢體語言，瞭解它們所表示的潛臺詞，試着從對方的角度看待問題。同時也要根據狀況採起不一樣的方法影響別人，有如下幾種方式，如表11-2所示：
表11-2
| 方式 |
簡介 |
邏輯/感情 |
推/拉 |
註解 |
| 斷言 （Assertion） |
就是這樣吧，聽個人，沒錯！ |
感情 |
推—— 主動推進同伴作某事 |
感情很強烈，適用於有充分信任的同伴。語音、語調、肢體語言都能幫助傳遞強烈的信息 |
| 橋樑 （Bridge） |
能不能再給我講講你的理由…… |
邏輯 |
拉—— 吸引對方，創建共識 |
給雙方充分條件互相瞭解 |
| 說服 （Persuasion） |
若是咱們這樣作，根據個人分析，咱們會有這樣的好處，a、 b、 c…… |
邏輯 |
推—— 讓對方思考 |
有條理，創建在邏輯分析的基礎上。即便不能所有說服，對方也可能接受部分意見 |
| 吸引 （Attraction） |
你想過溫馨的生活麼？你想在家裏發財麼？加入咱們的傳銷隊伍吧，幾個月後就能夠有上萬元的收入…… |
感情 |
拉—— 描述理想狀態，吸引對方加入 |
能夠有效地傳遞信息，可是要注意信息的準確性。誇大的渲染會下降我的的可信度 |
提示：沒有絕對正確或錯誤的方法，只有合適或不合適的方法。幾種方法能夠同時使用，只要使用者本人不會頭暈。
如何更有效地給合做夥伴提意見? 這個博客講了一個方法:
http://www.cnblogs.com/xinz/archive/2011/08/22/2148776.html
參考資料:
http://en.wikipedia.org/wiki/Pair_programming
<div class="clear"></div> <div id="post_next_prev"> <a href="https://www.cnblogs.com/xinz/archive/2011/08/07/2129751.html" class="p_n_p_prefix">« </a> 上一篇： <a href="https://www.cnblogs.com/xinz/archive/2011/08/07/2129751.html" title="發佈於 2011-08-07 00:09">技能的反面 - 魔方和模仿</a> <br> <a href="https://www.cnblogs.com/xinz/archive/2011/08/08/2130505.html" class="p_n_p_prefix">» </a> 下一篇： <a href="https://www.cnblogs.com/xinz/archive/2011/08/08/2130505.html" title="發佈於 2011-08-08 07:02">創新的時機 – 黃金點遊戲</a>