作者 | 廖雪青

前言

文章以真實項目實踐總結為基礎，選取了結對編程中的典型場景，敘述了在敏捷交付項目中，開發者在實踐結對編程時經常遇到的挑戰。場景中會找到你或你身邊同事的影子嗎？

結對編程的十個場景

角色假設

A：Senior DEV，結對編程實踐者

B：Junior DEV，剛接觸結對編程

場景一：結對前的約定

A：好，那任務列表(check list)我們梳理清楚達成一致了，現在要開始編碼工作了。你們之前是怎么結對編程的?

B：嗯～怎么結對編程具體指什么?

A：好吧，那不然我們一個人寫45分鐘，然后休息10分鐘，再交換?

B：好啊，可以的。

開始結對之前，做一些約定是較好的開始。協商結對編程過程中如何交換角色，多久休息一次等。例一：A寫 45分鐘，休息15分鐘，然后B寫45分鐘，休息15分鐘；例二：TDD A寫測試，B寫實現，A重構，B寫測試，A寫實現，編碼40分鐘左右休息10分鐘。

場景二：知識傳遞

A：休息時間結束，那我們開始?

B：好，該我編碼了。那我們接下來要構造接口的返回值了

A：對的，我們可以新建一個文件，導出一個方法，在該方法中構建接口返回值

B：嗯，那我們現在去找一個地方放新建的文件

A：可以在 XX 目錄下建這個文件...B找到對應的目錄并打開...

B：嗯。咦，這個目錄已經有很多文件了，我看一下其他文件都是干什么的。

A：嗯，其實這個庫有自己的模式，不然我們去看一下庫的文件結構說明文檔?

B：好呀，那說明文檔在哪呢?

A：README文件中有入口，可以從那里點進去。

B：哦。...查看結構說明文檔...

B：所以我們在給上游發請求前如果要構建請求參數的話，可以在文件夾下面建立XXRequestParams.js文件用來構建參數，從上游接口拿到返回值后，如果要對值做一些轉換的話，可以在文件夾下面建XXTransformer.js文件構建接口返回值。是嗎?

A：對的，這樣的話可以做到把部分功能放到單獨的文件中，避免文件過大。還有一個好處是更好寫測試。

及時發現結對編程的伙伴(peer)某方面上下文的欠缺并耐心傳達，幫助新人快速獲得項目知識。 當發現peer某方面的不足時，我們要意識到發展他人的機會來了。在上下文傳遞或知識點講解的過程中，我們可能也會有新的發現。

場景三：Senior直接上手解決問題

A：我們需要給 state 中增加一個 XX字段

B：對，我們現在要去state文件。這個文件，好像不是加到這個state文件呀!這個文件呢?不對不對，好像也不是。

A：我們要構建的頁面屬于XX模塊，得把state字段加在XX目錄下的state文件中。

B：嗯嗯，有道理。那這個文件，嗯～好像也不對!

A：不然我來寫吧。

...A拿過鍵盤，啃哧啃哧的編碼...

B：要遍歷數組了，用 for each 方法吧!

A：嗯～有其他遍歷數組的方法嗎?

B：還有 for…of、map 等方法，那我改成 map 吧!

A：其實這塊用 reducer 方法可能更合適

B：reducer 方法!reducer方法該怎么寫呀?

A：那我來寫吧。

...A拿過鍵盤，啃哧啃哧的編碼...

要給Junior足夠的實踐機會和成長時間。任何成長都是需要時間和實踐的，每個人學通一個技術或領域知識所需花費的時間也不盡相同，我們要關注peer取得的進步，而不是聚焦于peer還沒有掌握的部分，也不要因為peer的速度較慢就自己上手，剝奪他人實踐和學習的機會。

敢于暴露自己的弱點。 敢于承認自己在某方面的能力比較欠缺，尋找機會有針對性地進行提升，不要害怕暴露缺點而不敢發言。展示弱點并不會讓我們矮于他人，相反還會讓大家覺得你比較容易接近。

團隊要創建一個安全包容的環境。 團隊有好的氛圍，成員才不會擔心說錯，有更大的信心自由地發表自己的觀點。

場景四：一個人的獨角戲

A：任務列表的這一項太大了，不然我們把它拆小一些?

B：......

A：這塊邏輯很復雜，還不好寫測試，不然我們抽一個純函數去處理這段邏輯吧?

B：......

A：這塊代碼這樣寫好像不太符合項目的模式，我們去找個已有例子參考一下?

B：......

全程無回應(我是誰?我在哪?我在做什么?)。

是peer沒聽到嗎?是我聲音太小了嗎?是peer太專注沒心思搭理我嗎?

及時回應。溝通需要至少兩個人的參與才能正常進行，就像討論需要有來有往才是有效的。如果A講了話卻沒收到來自B的反饋，有三種可能情況：1. B沒聽到。2.B聽到了但是沒有回答。3.B聽到并回答了，但是回答的方式沒有被A理解到。對A來說，若不確定B究竟聽到沒，可以加大音量重復所講的內容。如果還是沒有回答的話，可以問A是否有聽到。為了讓結對編程更順暢，建議我們聽到他人說話后，及時給出回應，以示意我們聽到了。這個回應可以是語言、動作甚至眼神，所以如果我們正在思考，不能被打斷或不方便給出回應時，可以選擇動作等非語言的形式給出示意。

及時反饋。如果我們講話后沒收到對方的回應，要及時反饋。如果該現象發生了多次，我們可以建立一次反饋會議，跟peer針對該問題進行正式的溝通，分析原因，明確及時回應的必要，商討對應的解決方法。

場景五：你怎么都不會

A：我們用 reducer 方法來對數組進行處理吧!

B：這數組遍歷的 reducer 該怎么寫呀?

A：你這都不會!

...A講解 reducer 的使用方法...balabala… 一頓解釋...

B：測試要mock外部依賴了

...B開始編碼，嘗試了兩種mock方法，都沒有達到預期效果...

A：這塊結合實際情況，要這樣mock

...A講解該處mock外部依賴的方法...balabala…

B：對的，這樣寫測試結果符合預期。

A：你怎么這也不會!這很簡單呀。

注意溝通技巧、用詞和語氣。我們在溝通的過程中，一定要以平和的心態，不帶偏見的、盡可能客觀地表達我們的意見。有些用詞對你來說可能不帶任何含義，但是在他人來說就不一定了，所以斟酌用詞也是必要的，盡量使用常見的中性詞。當然我們也沒必要對每一個用詞語氣都反復斟酌，否則會過猶不及影響正常的溝通，畢竟都是項目的成員，說話的人和聽話的人的感受都值得被關注、被考慮。重要的是在發生不愉快的時候，我們都要有去解決的意識，能及時溝通講清前因后果及雙方的理解，解除不愉快。

正確處理peer的能力低于預期的情況。peer 的打字速度好慢呀，都不用快捷鍵，方法定位也不會，這么菜嗎？針對這些情況，要明確：聞道有先后，術業有專攻。如果 peer 某方面表現很不好的時候，不要隨意批判輕視對方，要知道 peer 在這方面比較 junior，但是在其他方面，我們也可能會是初學者，所以我們要換位考慮對方的感受，同時還要意識到發展他人的機會來了。針對具體問題也要具體分析，通過溝通等手段尋找問題根因。是因為 peer 剛接觸該技術棧呢？還是 peer 最近壓力比較大，沒休息好，所以有時會反應比較慢呢？亦或是文件搜索這塊正好是 peer 的短板呢？不管是客觀原因還是主觀原因，都要結合實際情況，多方溝通探討可行的解決方法并進行追蹤。

場景六：建議被忽略

針對一個問題

A：...balabala…(講完自己的思路)

B：...balabala…(提出一種新思路)

A：...coding…(按自己的思路開始編碼)

B：...%#@$%&

...…B很懵，貌似自己的方案更合適吧?怎么就開始編碼了呢?...

關注并重視自己和peer的感受。結對編程實踐下，一天的大部分時間我們都在和peer進行協作，如果心有隔閡，那么結對工作很難順利進行下去，所以在內心感到不適的時候，我們要重視自己的感受，及時反饋給對方并進行溝通，針對具體情況協商解決。

針對不同解決方案要溝通達成一致再編碼。如果結對的兩個人針對同一個問題分別提出了幾個方案，這時要針對這些方案進行溝通，確保雙方都理解了這些方案，并對方案的優缺點、工作量等有一定的理解，雙方都贊同采用某方案后，再開始編碼，避免實現到一半再出現分歧。這個過程中，可以對每個方案都從頭到尾梳理一下，能提前識別一些存在問題的方案并過濾掉。如果針對要采用的方案無法達成一致，可以考慮暫時擱置爭論，尋找支持論點的證據后，再開始新一輪的相互說服，也可以考慮引入第三方，TL或在該領域經驗豐富的組員都是較好的選擇。

及時反饋。反饋文化是我們所提倡的，可以建立多維度的反饋會議，比如peer的某種行為讓我感到不適，如果不想打斷工作進度且可以接受暫時不適時，可以選擇一天工作快結束的時候再進行反饋交流，總結一天的工作，識別一些做得好或值得深挖、保持的地方。

場景七：按自己的節奏走

...A啃哧啃哧編碼...無講解思路...

B：你在不同的文件之間跳來跳去的，是在干嘛?

A：我們要修改測試環境的配置。

...A繼續啃哧啃哧的編碼...無講解思路...

B：這又是在干嘛?我們不是要先去查看一下XX方法，然后看看能不能拿到我們想要的結果嗎?

A：嗯，對。

...A繼續啃哧啃哧的編碼...無思路講解......

B很懵，不知道A的思路是什么，也不知道A是按怎樣的順序處理問題...

共同貢獻，團隊擁有。結對編程實踐下，開發軟件功能是兩個人的事情，Senior 不要大包大攬獨自完成，只按照自己的節奏，而在沒有講解思路的情況下忽略了peer是否能跟上。Junior 也要為卡負責，不懂就問，進度太快就提出來，不要獨自承受壓力。

高頻率的溝通。結對編程實踐下，做卡是兩個人的事情，這需要高頻率的溝通以確保結對的兩個人都清楚理解該卡的上下文、解決思路以及當前正在做的事情是什么。在講解實現思路的時候，要細致到每一步(參考美食主播講解菜譜的過程)，畢竟peer的思路可能完全不同。

場景八：表現出被針對

項目組每周交換一次結對伙伴，剛交換結對伙伴后，A新加入該功能的開發。

...B給A同步正在實現的功能的上下文...

A：停，打斷一下，這個方法為什么要先過濾再遍歷數組呢?

B：因為...

...B反應激烈，聲音拔高...

...A感覺peer豎起了盾牌...

當有新成員加入卡時，同步卡的上下文。需要同步卡的范圍(scope)，當前進度，是否有阻塞(blocker)等。在同步的過程中，講解者能再次梳理卡的內容，有可能發掘之前忽略的小細節，接聽者通過提問等也有可能提出不合理的地方，為卡的質量增磚添瓦。

結對編程時，大家的建議和爭議都是對事不對人的。在結對編程的過程中，意見并不總是一致的。當發生爭議時，作為被挑戰的一方，應該客觀地傾聽別人的意見。如果之前沒有充分考慮，要勇于承認并接受別人的意見，而不是認為別人在攻擊自己，急于辯解并不斷反駁。即使別人提出的建議很有道理，也不要因維護自己的虛榮心而拒絕采納。可能團隊成員缺乏足夠的上下文信息，而挑戰只是發出需要同步上下文的信號。要相信別人提出建議是為了讓我們的代碼更加可靠或者需要更多的上下文信息來理解我們正在做的事情。作為挑戰的一方，我們需要注意用詞和語氣。我們的目的是提出想法，保證代碼質量，而不是通過發表建議來展示自己的能力和不凡。我們應該保持客觀的態度，使用平和的語氣。如果感到對方比較排斥，要及時澄清情況。

場景九：因為私人事情離開

...A正在思考著解決方案，邊思考邊講述著自己的思路...

...B突然離開...

...A猜測B是因為私人事情離開，感受很不好...

團隊信任很重要。首先，我們不能主觀評價peer離開的原因，也不能評價事件的重要性。其次，我們需要具備基本的職業素養，盡可能專注于結對編程，不在未溝通的情況下無故離開，除非情況緊急。

在每天開始結對編程前，要檢查當天的日程并同步可結對的時間段。提前同步可結對時間可以幫助規劃卡的工作，例如在兩個人都能結對的時候確定解決方案，或先實現一些復雜邏輯。這樣，在一個人離開后，另一個人可以無障礙地繼續編碼，避免遺留下來的人無法確定解決方案或無從下手處理復雜邏輯。

如果需要在結對編程過程中離開，盡量使事情透明。結對編程需要兩個人頻繁互動，因此考慮到peer的感受可以建立良好的關系，有利于結對編程的順利進行。如果我們正在專注于結對編程，因為突發情況需要離開，盡量告知peer，方便的話講清離開的原因及預計返回時間，這是對他人的一種尊重。

相信 peer 是專注于結對編程的。在專注于結對編程的同時，我們也要相信 peer 也是專注于結對編程的。如果peer在沒有通知的情況下離開，我們應該相信是因為情況緊急而沒有來得及通知，而不是因為工作態度有問題。

離開的人回來后，留下的人應該主動同步這期間的代碼改動等。代碼改動等同步可以讓peer了解卡的最新狀態，方便在下一步的編碼中提出有效的建議。如果留下的人沒有主動同步，離開的人也要主動詢問改動內容，以便及時將注意力集中到當前的任務上。

場景十：peer 分心做其他事

...A在講解一個解決方案的思路，講著講著發現B在看手機...瞬間沒有講解的欲望了，那自己繼續編碼吧...

...過了一會…

B：你剛才說什么?

...A偷偷嘆了一口氣，把剛才講的內容重復了一遍...

A：我們這是不是應該提取個方法呢?...

等了20s左右無回應，轉頭一看，B在瀏覽網頁...

...過了一會…

B：現在到哪了?

A：......

在進行結對編程時，應盡量避免分心。不要進行類似閱讀郵件或使用手機等的活動，要專注于結對編程。如果出現特殊情況需要隨時查看郵件來確認某件事情，就應提前溝通，讓這個事情透明化，而不是等到出現矛盾時才采取事后措施。

在規劃結對編程時間時，要預留一些時間。確保每個人都有足夠的時間閱讀自己的電子郵件。

總結展望

結對編程是一項需要團隊合作的實踐，也是一項復合技能，應用場景十分廣泛，不能一一列舉。我們應該在結對編程中不斷磨練這項技能，提高結對編程的體驗和價值。同時，在遇到困難時，也要敢于迎難而上，尋找解決方案。

最重要的是，我們應該認識到結對編程是一項團隊實踐，遇到的任何問題都可以從團隊中尋求幫助。