對於軟件開發者來說，敏捷開發並不是一個新詞。自1990年開始流行至今，敏捷開發已有近30年的歷史。它因對需求響應迅速、注重團隊溝通、可持續快速交付等優勢令人稱道，然而也有相當一部分人認爲，不同成員間的協作可能會帶來更多問題，使整個流程變得更加低效。關於敏捷開發的使用，始終存在很大的爭議。
近日，移動互聯網出海企業觸寶的研發總監孟雷在出席 ArchSummit全球架構師峯會2019深圳站 時提到，作爲敏捷開發的方法之一，結對編程在國內仍是一個小衆的軟件開發方式，而觸寶正是採用這一方法的少數企業之一。據瞭解，採用結對編程後，半年內，觸寶電話在海量用戶的前提下實現了高質量地從每月一個版本的發佈週期逐漸提升至每週一個版本的快速迭代。同時，線上P1級bug數量減少至原來的5%，代碼架構、模塊化程度以及團隊都更加高效。所以，結對編程真的像傳說中那樣不具有可操作性嗎？什麼樣的團隊適合結對編程？結對編程會爲企業與個人帶來怎樣的改變？
在ArchSummit全球架構師峯會2019深圳站，觸寶研發總監孟雷發表了主題爲《如何通過結對編程進行高質量的軟件開發》的演講，以下是InfoQ在大會期間對孟雷進行的採訪全文：
InfoQ：您可以簡單介紹一下目前在觸寶負責的業務和具體開展情況嗎？
孟雷：我在觸寶目前主要負責觸寶電話的相關業務。除了技術方面，還包括商業化以及增長推廣的工作。我們在國內也正在孵化一些新的內容類APP，具體也是由我負責。
InfoQ：我們瞭解到，您過去專注于敏捷開發。敏捷開發在國內有很大的爭議，很多人說，國內做敏捷開發是爲了“甩鍋”，我們採用的敏捷開發並不是真正的敏捷開發。您認爲產生這種誤解的原因是什麼？
孟雷：我平時和很多朋友的公司團隊交流，在交流過程中，我發現比較常見的問題是大家對敏捷的定義往往過於表面。過於表面是說大家很容易就學到敏捷的一些形，這些形包括怎樣組織文檔，怎樣開會，怎樣把工作一個個拆分完成。這些資料市面上都有，大家就拿過來直接用了，但並沒有思考這麼做的原因。從某種程度上，大家還是在做瀑布式的軟件開發，只不過是把一個相對長的瀑布的週期縮短成了一個相對短的敏捷的週期。在這個週期裏，大家所做的事以及做這件事的思路和瀑布時代沒有特別大的、本質的區別，這一點是大家比較容易進入的一個誤區。之所以會出現這樣的問題，我覺得主要原因在於，敏捷開發是一個舶來品，大家在過去幾十年還是比較適應傳統的軟件開發方法。當這個舶來品來了的時候，人們很容易直接把它套進去，但並沒有做深入的思考。
InfoQ：您說敏捷開發是一個舶來品，那麼，結對編程也是舶來品嗎？
孟雷：是的。爲什麼我會引入結對編程這個概念呢？其實嚴格來講，結對編程也並不是一個非常新鮮的事物，很早以前就有人提出並實施了。目前，它的應用場景更多是在一些編程競賽，或幾十個小時的極限編程中，而真正把它推廣到工程層面的人和公司都非常少。我爲什麼會發現它，並在一定程度上把它進行實踐呢？我之前曾經在EMC子公司Pivotal工作，Pivotal本身是硅谷一家特別極客、新銳的公司。我在公司接觸到將近一千人，大家幾乎全部是用結對編程的方式推進任務的，這在當時的業界非常少見，所以一開始我也不太理解。後來經過實踐，我才發現，結對編程和敏捷開發是非常契合的。敏捷開發本身需要“小快靈”，但在“小快靈”的同時，又不能犯太多的錯誤。總結下來，我覺得結對編程是解決這個問題的非常好的思路。
InfoQ：您覺得結對編程主要適用於何種開發環境？國內團隊可以在哪些情況下嘗試結對編程？
孟雷：從我個人的體會來講，如果大家真的有決心嘗試它、使用它，其實它的適用範圍是非常廣的，任何公司和組織應該都是非常適用的。但是相對來講，把結對編程落地這件事在國內還是比較少見的。我們可以在一些小團隊，或者偏極客氛圍的團隊和公司先用起來，在局部取得比較好的效果後，再慢慢推廣。
InfoQ：結對編程解決了工程或技術上的哪些難題？可以爲企業或個人帶來怎樣的收益？
孟雷：通過結對編程的方式，我們可以在編寫代碼初期對它的架構、設計進行討論，也可以更清楚地看到整個編寫過程，更早地發現一些潛在的問題，尤其是設計上的問題。如果在設計階段就能有一個比較好的處理，好過在測試階段，甚至發佈後，發現問題再補救，前者付出的代價要小得多，這就是結對編程爲公司或項目帶來的主要好處。對個人而言，它也是一個非常好的實踐。我們可以將新老員工搭配，Senior和Junior的人搭配，這樣一來，Junior的人的水平可以得到比較明顯的提升。這是我的一個看法。
InfoQ：有人認爲，結對編程對開發者的默契度要求較高，如果配合不好，反而會使整體效率降低。您如何看待這種說法？可以和我們分享一下您帶領團隊的經驗嗎？
孟雷：這個地方我需要澄清的一點是，結對編程並沒有要求兩個結對的人天生有什麼默契。結對編程在實踐時，爲了取得比較好的效果，需要人員的不斷輪換，所以它並不是固定搭配。在輪換的過程中，大家有不同的意見和想法都是非常正常，或者說非常正確的。因爲在某種程度上，做結對本身就是要讓不同的意見或設計理念進行碰撞和討論，所以實際上我們並不指望大家有多麼高的默契度。當然，當人們有太多的碰撞和討論，甚至產生爭議時，我覺得Team Leader要做的事情就是把握好一個度。一方面，你要讓大家有適當的分歧和爭論，因爲這樣才能保證代碼寫下去是大家共同接受的結果，而不是某一個人的想法。但另一方面，當爭論過於激烈的時候，Team leader要適時介入。你要去具體地看，討論的到底是什麼問題，這個問題的正確解法是什麼，我們能不能達成一致，如果不能達成一致，可能就需要把它拓展到更大的範圍，大家一起來討論解決。
InfoQ：結對編程和普通開發模式下的編程，在團隊管理上最大的區別是什麼？
孟雷：最大的區別是，結對編程看待項目和人員的角度更加統一。無論是Teamleader也好，Team成員也好，他們都會慢慢地通過結對編程對整個項目、整個編程的設計理念和方法有相對統一的認知。就像我前面所說的，在這一過程中，也會有一些爭議和分歧，那麼我們就要懂得如何在統一和分歧間把握好度。
InfoQ：您可以談談結對編程在企業中的普及情況嗎？除了觸寶之外，國內還有哪些公司也在採用這種方式？您還知道哪些比較前沿、極客的軟件開發方式？
孟雷：據我所知，硅谷一些比較極客的公司在用結對編程。在國內，結對編程還屬於比較小衆的軟件開發方式，使用它的公司相對較少。目前來講，除了結對編程，業內大家談論的比較多的可能就是TDD了，就是Test Driven Development。我覺得這兩者並不矛盾，TDD更偏向於測試驅動開發，更強調測試。結對編程並不完全強調測試，而是更強調開發人員結對進行測試，測試力度也非常大。除了開發人員的互相保證之外，結對編程是靠一整套的持續集成和線上監控機制來確保軟件開發的完整性的，所以我覺得兩者可以有機地結合。
InfoQ：您剛剛說到測試驅動開發，現在有觀點認爲，開發也要懂測試，測試也要懂開發，運維也要做開發，開發也要做運維。您如何看待不同技術工種越來越趨向於融合的狀態？未來會出現“獨立的測試沒有了，運維沒有了”這種情況嗎？
孟雷：根據我的經驗，應該是不會的。儘管我們說，開發也要做些測試的工作，但就開發人員的工作重心與特性來講，他們更適合做功能性的測試。所謂功能性的測試，是指我要做一個功能，這個功能自身是否完整，是否可用，這方面的測試由他們來做是比較合適的。但是當你把移動互聯網的軟件發佈到線上，就會發現，除了功能測試以外，還有很多其他方面的測試。比如發佈到安卓平臺，安卓平臺的碎片化特別嚴重，終端機型特別豐富，你就要把這些機型全部覆蓋，那麼僅靠開發人員就是不現實的。有時，很多Bug在小規模的集羣或用戶中是不會爆發出來的。這個時候，一方面我們要有更專業的壓力測試。另一方面，有些問題真正到線上時，一定要通過數據運維的監控才能看到，這些相對就屬於更專業的測試領域。如果開發人員花費更多的時間來做這些事，他個人的項目進度可能相應地就會受到一些影響。從這個角度來講，粗略的工種分配還是會一直存在的。
InfoQ：我們瞭解到，您曾經推動建立了觸寶電話的完整的研發測試流程，您是如何平衡軟件交付與質量之間的關係的？
孟雷：一開始，我們迭代速度比較慢，又想向前快推的時候，遇到了很多問題。因爲，當你想快推的時候，整個代碼質量就會大打折扣。因此我結合之前的經歷，推行了結對編程的方式，之後就發現它在某種程度上可以解決敏捷裏面遇到的一些問題。它可以在整個過程中，既保證代碼快速迭代，又保證高質量。至於效率問題，剛開始做這件事的時候，因爲大家都不太熟，所以整體效率是會有一點降低，畢竟是兩個人做原本一個人做的事。但當這件事執行一段時間以後，它就會處於一個相對穩定的狀態，大家對這個模式熟悉之後，效率是會倍增的，相當於你寫的每一行代碼都經過完整的討論和分析，所以它的質量更高，返工次數更少，後期花費的時間也更少。
InfoQ：結對編程會增加用人成本嗎？
孟雷：嚴格來說是不會的。雖然是兩個人在做一個人的事情，但相當於把後期的代碼review，交互測試等方面，兩個人一起完成了。也就是說不像傳統開發，寫完代碼以後還要做code review，結對編程基本上是一次就過的。其實code review階段，大家往往都比較忙，有時候也並不能真正做到有質量的review，這樣就會導致你前面埋的一些雷，到後期慢慢地爆發出來。所以像過去那樣，有時質量也不好。兩種方式比較起來，我覺得結對編程的效果是不錯的。
InfoQ：觸寶的技術團隊在質量把控上有着怎樣一套系統、完整、科學的方法流程？
孟雷：首先是採用結對編程寫出質量較高的代碼，同時我們專業的測試人員會做一些具有擴展性的，更系統的測試。同時，在正式發佈後，我們相關的運維監控也會配套。做到從開發到測試到監控三方面的良好配合，從而達到比較理想的質量。
InfoQ：未來五年，觸寶還將發力哪些前沿技術領域？
孟雷：過去，觸寶主要做面向大衆終端用戶的一些基礎性工具，比如觸寶輸入法、觸寶電話。這種都屬於比較小、輕的工具，整體的用戶數量和規模都比較大。未來，除了工具，我們還要做很多新產品。隨着用戶數量的不斷增多，結合觸寶產品與用戶交互的天然特性，後期我們會在大數據和AI方面持續投入。
嘉賓介紹：
孟雷，觸寶個性化工具與內容事業部研發總監。曾先後就職於微軟中國、EMC 中國，擔任軟件研發相關工作，專注于敏捷開發及分佈式自動化測試的實踐與團隊管理。曾獨立負責微軟 SCCM 軟件分發體系的測試，主導微軟內部雲測試和雲部署服務 NOVA。在 EMC 任職期間成功推進 Pivotal 內部的敏捷開發轉型，從零開始參與了 Pivotal Hadoop 的最初三個版本，並主導研發了適用於 Hadoop 系統測試的分佈式測試框架 laphone。對於傳統企業級軟件如何進行敏捷研發的轉型有豐富的經驗。任職觸寶期間，推動和建立觸寶電話完整的研發測試流程，加速產品迭代，在保證高質量的前提下，實現了一週一發布的快速迭代週期，並培養了一大批精通移動互聯網前後端、客戶端開發的高素質研發團隊人員。