結對編程成為主流，但反響冷淡
英文原文：Pair Programming Gets Mainstream Coverage, Lukewarm Response
作者 Todd Charron 譯者巨澤建
華爾街日報開始注意到越來越多的技術公司在實踐結對編程，并在題為“計算機程序員在共享中學到深刻教訓”的文章中發表了自己的看法。
在技術公司中，結對尋找到了支持者。這些公司包括 非死book 和移動支付創業公司 Square。結對的倡導者對結對的力量贊不絕口，聲稱結對程序員可以捕獲不采用結對時需要花很大代價才能找到的軟件錯誤，而且不太可能花時間上網沖浪。
然而，他們很快在實踐中發現了問題，就好比約會一樣。
現實更像一個永無休止的糟糕的約會。任何困擾同伴的煩惱很快就堆積如山：從不良個人衛生和辦公桌整理習慣，到把腳翹到公共桌子上并且大聲咀嚼。Pivotal Labs 是一家軟件開發公司，三月份被技術巨人 EMC 并購。Pivotal Labs 的 175 名工程師每天都在結對。一些人不夠專一，每天都換同伴，稱為“混雜配對”。
繼續拿約會作類比。
解決與結對同伴的問題，與解決你重要的另一半的問題非常像。“這與任何關系一樣，”Kite 女士說，“如果不談論這些問題，就無法繼續工作。”
這篇文章以咨詢公司 Drive Current 的故事和他們結對編程的經驗作為結尾。
讓公司工程師每天三個小時結對，堅持兩年之后，Kocol 先生在 9 月份淘汰了這種做法。“我認為任何人都不會非常想念它。”St. John 先生說。
一些開發者加入進來，在評論中發表了他們對結對的看法和實踐經驗。Anne Bennet說道，
這聽起來太可怕了。我們曾有一個經理討論過結對，萬幸他已經離開了。謝天謝地我快退休了。我能理解另一個人來檢查代碼，但是一起寫代碼？不適合我。
Mike Edwards 有一些正面的結對經歷。
我的經驗是，對處理那些已經長期忽略并不再維護的遺留代碼的程序員來說，結對編程非常有用。有一個目擊證人在旁邊，這項工作會更好受些。
Christopher Wong 認為這取決于各人的個性。
我發現結對編程就像整天困在會議里。我發現這非常累人，讓人耗盡精力。但有人因這種安排而充滿活力。這看起來是一種個性問題，應該由參與者自行判斷。
Catherine Jefferson 可以看到它的好處，但認為對她沒用。
如果我強迫自己靜下心來，思考一下結對編程，我可以想象出，對于有些人和有些類型的編程，結對可能有用。但如果讓我在工作中做稍微類似的事，我會在一天甚至更短的時間內筋疲力盡。[顫抖]
Thomas Gordon認為這是一種時尚。
哇喔，這個有意思，是種編程時尚。我只是開始擔心會混亂，有人要坐在我的膝蓋上。我個人很好奇這種共享桌面的方式可以工作。我發現絕大多數程序員真的非常喜歡他們自己的想法，我真的很好奇有人會使用不同于首次出現在他們頭腦中的方法解決問題。
并非所有人都認同華爾街日報的評價。Roger Neel 是 Mavenlink 的共同創始人和 CTO，他感覺這篇文章對結對的描述并不公平。在他看來，華爾街日報對結對編程理解錯了。
我們很早就決定用 Ruby on Rails，開始尋找早期的開發伙伴。我們找到了 Pivotal Labs。在我們項目范圍內（Davis 和 Rajan，你們好！），我們討論了 Pivotal 普遍的敏捷實踐，極限編程，測試驅動和結對。當時對我們來說，結對是一種讓我們基于他們的最佳實踐進行訓練的極好的方式。我當時不知道我們會在接下來的三年里在那里工作，并基于敏捷編程雇傭我們自己的團隊。
Roger 找出了華爾街日報的例證中的毛病。
感謝為我們提供了一個公司的例子。但是，該公司的文化不喜歡結對，該公司的人不喜歡結對。然而，所有其他那些喜歡結對的公司和人呢？
他解釋了結對的好處，并把結對和瑜伽進行了對比。他解釋了兩者最初看起來都比較怪異，還解釋了瑜伽是如何變成一種主流活動的。
結對的重點是合作，寫出更好的代碼，教導并讓雙方相互檢查。經過一些練習，合作和交流想法變得更加容易。但并非每個人都能像 Kent Beck 提到的那樣，“嘟囔兩句就能出代碼”。只要你覺得腿還是僵硬的，你就不會停止練習瑜伽；同理，因為你需要一些（或很多）交流，你就不會放棄結對。
Roger 認為結對還有其他好處。
結對編程和日常結對輪換可以減少對【很多會議】的需求。如果我們在產品中經常輪換，任何人都會經歷多條并行的業務開發軌跡，所以任何一對都可以在日常工作中自己做決定。。盡管承認結對并不適用于所有人，Roger 還將結對與其他常見實踐方法進行了比較。。
一種傳統模型是單獨構建軟件，定期做代碼審查，彼此相互作教練。當一個組織非常訓練有素時，這種做法很好。但是在現實中，，通常每個開發者都會在每天八小時中需要寫 16 個小時的代碼。所以他們最后想的事情是，這是別人的問題。另外，沒有上下文或長時間投入，我怎么假定我會搞清楚某個問題？針對這個問題，另外一些人已經工作了幾天了。短時間的評審經常會導致表面的重構，而非深入的討論和提高。
通過結合敏捷設計技術和持續的交流與輪換，結對編程是不斷達成一致的極好方法。而不是各做各的互不交流，然后事情做到一半又打回重做。
</blockquote>你的結對經歷是怎樣的？如果你是一個結對迷，你怎樣把你的想法呈獻給那些對這種實踐不熟悉的人？
注意：你也可以查看我們關于結對編程采用情況的調查結果，或者自己進行投票。
來自: InfoQ本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！