一、簡介
Pair programming 出自於敏捷式軟體開發 (Agile development approach)，是軟體工程師合作開發程式一種方法，中文譯為「結對開發」(下均採用原文)。
在 Pair programming 中分別有 2 個角色共同開發同一個程式任務，分別是：
- Navigator (導航者)：負責觀察、規劃、回饋、提出戰略性程式碼撰寫的方向
- Driver (駕駛者)：負責寫程式
在進行 Pair programming 的過程中，2 位工程師會使用同一台電腦、聚焦在同一個畫面、針對同一支程式一起開發。
拜現在技術愈來愈方便，2 位開發者也不必真的使用同一把鍵盤、同一個螢幕，可以使用軟體 (例如 — VSCode — Live Share 達成同樣的結果。這就好像我們使用 Google Doc、Google Sheet 一樣，你可以看到另一位同事的游標在哪個地方。
二、Pair programming 的優點
讓 2 位工程師同時做一件相同的事情，如果沒有特別的優點與回報，任何一個老闆都不會買單的。經過整理，我發現優點主要有 3 個：
- 提升程式碼品質
- 提升知識傳播效率
- 提升團隊運行效率
1. 提升程式碼品質
根據美國北卡羅來納州立大學 (NCSU) 研究 發現：
Pair programming 雖然增加了 15% 的開發時間成本，但提升了程式設計品質、技術技巧、團隊溝通，同時也減少程式缺陷、員工缺席造成的風險。
(They found that for a development-time cost of about 15%，pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.)
例如原先一個人需要開發 180 分鐘的程式，使用 Pair programming 需要花費的工時為 180 * 1.15(增加的時間成本) * 2 (人) = 414 分鐘 。
但同時程式的缺陷 (defect) 也少了 15%、程式設計品質 (例如程式碼行數) 少了 15%。缺陷減少代表著測試人員 (QA) 的總測試時間與工程師修復 Bug 時間下降 ; 程式碼行數減少代表程式複雜度下降，運作的效率更高。
有效的 Pair programming 可以讓程式碼的品質變得更好。
2. 提升知識傳播效率
在 Pair programming 過程中，工程師可以互相提出疑問與看法，在即時討論的過程中能夠加快知識的傳播。
參考 《Pair Programming 帶來的好處》一文中工程師的自述：
例如 Driver (撰寫程式的人) 在寫程式的過程中，突然停下來思考「某個環節使用 IF-ELSE 寫法是否會違反開放封閉原則 (Open-Closed Principle)，使用另外一種寫法是否會比較好」、或是「這樣的資料庫與模型關聯設計是符合專案當下最好的做法嗎？」這些問題都可能讓一位工程師無法推進進度。
對 Driver 而言，此時如果多一位夥伴可以對話，單純的將腦中的想法與問題提出來討論，問題就能夠迎刃而解 ; 對 Navigator 而言，可以從旁觀者的角度試著去理解 Driver 寫的程式碼，如果程式碼不好理解，Driver 有可能要修改程式碼來增加可讀性。
當雙方互相交換寫程式的經驗與對專案程式碼的理解時，無形之中就在加快知識的傳播。
3. 提升團隊運行效率
由於 Pair programming 可以提升知識的傳播效率，因此能夠舒緩組織的人力負擔。
在組織中，通常每個產品的系統模組會有一位負責人專門維護。多數情況是，這位負責人如果請假、離職時，這項產品的系統模組就沒有人可以接手了…雖然公司名義上有指定代理人，但是沒有特別的訓練安排，大家其實只清楚自己負責的系統運作邏輯。
Pair Programming 可以讓系統模組的負責人與另一位成員結對，在過程中讓成員慢慢熟悉另外一套系統的邏輯，無形之中增加彼此互相 Cover 的能力。
三、Pair programming 的缺點
Pair programming 的缺點也是顯而易見的，主要有 2 點。
1. 專案時間增長
如同前面所說的，Pair programming 會讓一位工程師執行的工作時間增長 15 ，同時還必須花掉另外一位工程師的時間，等於讓專案的時間變成了 2 倍。
對於正在趕工的專案來說，專案時間增長肯定是潛在延遲上線的風險。對於專案經理、管理階層、老闆等利益關係人來說，基本上是很難接受的。
2. 消耗大量專注力
從 Pair programming 的運行機制來看，可以感覺到工程師需要比平常工作更大的專注力。
根據資深工程師 Yuren Ju (小朱) 在星箭廣播第 112 集的分享，他認為 Pair programming 很像是專屬工程師的會議，這個過程比單獨寫程式真的累太多了！不論是 Navigator 還是 Driver，過程中都要不斷的觀察、思考、提問。
四、Pair programming 使用時機與注意事項
看完了 Pair programming 的優缺點，那到底什麼時候要使用這項技術呢？使用這項技術的過程又要注意些什麼？
使用時機
不是所有時間點都適合使用 Pair programming。
敏捷大師 Teddy 在《搞笑談軟功》建議在以下的時機使用 Pair programming 比較好：
1. 重要新功能的 coding 工作：如果系統的架構與設計已經有了大致的想法，此時採用 pair programming 是一個不錯的時機。但如果連這件工作倒底要如何開始都沒有任何頭緒，此時可以考慮兩人先快速討論一下設計，或是先分頭思考一下各自的解決方案，或是 google 一下可能的解法，然後在「合體」繼續開發工作 。2. Big Refactoring：如果要用 refactoring 改善系統架構或是重要設計，此時採用 pair programming 方式會比較保險，避免不必要的錯誤，或是不斷的 refactoring。由於做大範圍的 refactoring 一不小心很可能會發生鬼打牆事件，同樣的模組不斷地改來改去，有另外一個人一起幫忙看著可以可以避免這樣的情況發生。3. 帶新人：有新人加入用 pair programming 是最容易讓新人快速上手的一種方法之一。4. 知識傳遞：為了避免系統中每一個模組只有某位特定開發人員知道如何修改，以及為了達到 shared code 的目標，採用 pair programming 是一種快速傳遞知識的方法 。5. Debug：假設某個模組有一個 bug，但是對於這個模組最熟的開發人員卻看不出問題出在哪裡。此時可以找團隊中的抓蟲高手（例如 Teddy…XD）或是其他閒閒沒事做的人一起來幫忙看。通常有人一起看會節省很多 debug 的時間。6. 寫測試案例：自己一個人寫（自動化）測試案例很容易會忽略一些很重要，或是看起來不是那麼重要但卻是必要的測試案例（例如例外情況測試）。或者是有些自動化測試案例真的很不好寫，此時採用 pair programming 可以幫忙撰寫出這些測試案例。
歸納這些使用時機可以發現，使用 Pair programming 時至少要有 1 個人對執行的任務很熟悉，或至少在任務需要使用的知識領域上很瞭解。
如果 2 個人都是新手、或是對執行任務需要用到的技術或知識根本不熟悉，那還不如分頭研究再回頭討論比較有效率。
使用過程注意事項
除了使用時機外，在使用過程上也有些訣竅。
整理網路上曾經使用過 Pair programming 的工程師心得，使用這項技術時有以下注意事項：
1.使用時機與次數
建議使用蕃茄鐘循環，執行 25 分鐘休息 5 分鐘。一天最長不要超過 3 小時 ; 一週最多不要超過 3 次。
2. 結隊成員挑選
- 2 位新手或是對任務不熟悉的人，不要配對在一起
- 2 位會吵架的成員，也盡量不要結隊在一起
- 2 位都很熟悉工作的人、或是工作性質很簡單，不需要 pair programming。
3.執行主題
需要花時間研究的新主題盡量不要結隊，先各自研究有了成果後再配對。
五、Pair programming 對我的啟發
研究了 Pair programming 的來龍去脈後，讓我有 3 點啟發：
1. Pair programming vs Coaching
Pair programming 很像是 Coaching (教練)，但 Coaching 比較著重在教練給予訓練者的技能指導上 ; Pair programming 則是參與雙方共同解決一個問題，並且在過程中同時學習。
2. Pair programming 的應用
Pair programming 的概念也可以應用到其他領域，改變傳統的學習方式。
以攝影、魔術為例，傳統上都是老師說一動學生做一動的授課方式。如果借鏡 Pair programming 的精神，則是雙方共同解決現實中的一個問題，從過程中學習。
例如老師與學生共同使用同一款道具 (撲克牌)，要表演同樣的魔術程序時，學生先表演、老師觀察並且提出討論為什麼這個地方會想要這樣做動作 ; 接著轉換角色，老師表演同一套程序、使用同樣的手法，並且詢問學生過程中怎樣執行手法會更好。
再看攝影的例子。
例如老師與學生使用同一款相機，要對同樣的風景、Model 拍攝。學生先拍攝、老師觀察操作相機的動作 (焦段、光圈、快門速度、測光…等) 以及照片成果，討論過程中應該如何執行會更好 ; 接著轉換角色，換老師拍攝同樣的景物、Model，過程中老師確認每個動作的執行學生都有搞懂，再往下進行。
3. Pair programming 也是教學技術的應用
王永福 (福哥) 在 《教學的技術：翻轉課堂的職業講師祕訣》中提到：
教學中最讓我們挫折的就是：自己(認為)已經用最有條理的方式教學，但對方似乎有聽沒有懂。
為什麼會這樣呢？
因為知識的建立奠基在「模仿」與「個人的自主思考」。
也就是說，如果老師不做給學生看、學生不自己動腦/動手演練一遍，是無法學會新知識的。
Pair programming 就是不斷讓學生 (學習者) 動腦的過程，透過主動思考與提出問題，讓學習效果變得更好。
當學習者卡關、學習上逐漸喪失注意力時，Navigator 適當的提問與引導可以拉回學習者的注意力。
六、結論
Pair programming 雖然是軟體工程開發的技術，但精神值得其他領域的人學習。這篇文章中整理了 Pair programming 的：
- 介紹
- 優點
- 缺點
- 使用時機與注意事項
- 我的啟發
希望對 Pair programming 有興趣的人有幫助。
參考資料
- 觀念
- 星箭廣播 112: 軟體工程師團隊怎麼工作？Pair Programming 結對開發實戰經驗談（ft. 資深工程師小朱）
- 【文思不藏私】@千萬不要『結對編程』. 首先，這一篇是教你『不要用結對編程』（Pair… | by Vince Huang | Medium
2. 個人經驗分享
3. 工具
▶ 關於文章1/ 歡迎訂閱 我的電子報 獲得實用的生活與工作技巧，每週二中午 12:00 準時發刊2/ 想要掌握最新文章，可以點擊下方「Follow」我～3/ 如果你覺得文章寫的不錯，可以對文章拍手讓我知道 👏🏻▶ 關於我我是朱騏，一個組織能力超強的軟體產品經理，喜歡研究各種生產力工具、時間管理方法。1/ 我可以提供產品管理、時間管理、生產力工具的「個人問題諮詢」與「講座邀約」。2/ 若是個人諮詢，可以請我喝杯咖啡、吃頓晚餐，可透過 Email/ Facebook 跟我約時間，請參考「聯繫方式」。3/ 若是講座邀約，請直接使用 Email 聯繫。︎▶︎ 聯繫方式- 📪 Email：muhenry608@gmail.com- 💬 Facebook：請先加我個人好友並簡短說明想要諮詢的主題▶︎ 建立人脈歡迎使用 LinkedIn 與我交流，你可以「加我為好友」建立連結| LinkedIn @ Chi Chu 歡迎交流
