台灣的Web工程師

緣由

最早得知 Pair Programming 這個東西，是從一本「eXtreme Programming理論與實務 」看來的，

這本書主要是針對 eXtreme Programming 這種軟體開發方法來描述，但是這本書讓我印象最深的則是Pair Programming；

Pair Programming是eXtreme Programming 這種軟體開發方法中的其中一環，而作法則是由二個人去實作相同的程式功能。

由「二個人去實作相同的程式功能」，對RD來說聽起來很好，但是對付錢的人來說，可能會認為「為什麼相同的工作需要二個人」，

所以 Pair Programming 在商場上其實很少看到。

但在公司中有一些機會去帶新人，所以就把這個 Pair Programming 模式套上來了，實際試驗過後，有一些心得可以分享，

不過在分享之前，因為也曾有過有人聽過這個 Pair Programming ，但實際上不清楚，所以我先說明一下如何實作 Pair Programming 這個東西。

方法

在介紹方法之前，先說明一下在Pair Programming中的專有名詞：

• Driver（駕駛者）⇒ 鍵盤的控制者，負責輸入程式的人
• Observer （觀察者）⇒ 旁邊的觀察者，負責確認駕駛者輸入的內容

這二個角色即是Pair Programming中的全部角色了（廢話，不就二個人而已嘛）。

而執行Pair Programming的方法如下：

1. 先選定二個人為一對，分別擔當不同的角色（在不同的情境下，針對二人的選擇有不同的建議，這在之後再詳述）。
2. 二個人只有一台電腦，並看向相同的畫面。
3. 每15分鐘交換角色，即原先的Driver變為Observer，原先的Observer變為Driver。

上述這三個重點，即是Pair Programming的執行方法了。

優缺點

在執行Pair Programming上，一般認為的優缺點如下：

優點

• 加深理解：因為二個人在過程中往相同的目標前進，故針對商業邏輯與程式邏輯，都會比一個人Coding時理解的更深。
• 降低Bug發生率：因為在Coding的同時，觀察者會負責Code Review，所以Bug的發生率會比較低。
• 工作人員備份（交接）：因為是二個人同時理解商業邏輯與程式邏輯，所以即使其中一人請假，也會有另一人可以處理。

在工作上最常遇到的，當負責特定程式的Ａ人員請假＆這段程式邏輯只有Ａ知道，此時常見的方法則是：打電話給Ａ 或 等A回來吧，

如果我是Ａ的話，​​我最討厭當我在休假中，有人打電話給我問公事的這種狀況了，基於這個理由，其實我還蠻推崇Pair Programming的。

缺點

• 專案工時加大：因為二人負責相同的功能，所以工時變成２倍，但書上有說，增加的工時會在「降低Bug發生率」與「工作備份」這一塊拿回來。
• 無法偷懶：因為二人會共享時間，所以私人時間會變少，換句話說，會變得無法偷懶（對筆者很重要，所以標起來）。

關於缺點的「專案工時加大」，在因為在「降低Bug發生率」與「工作備份」這二塊很難數據化，所以雖說實際的工時不會變成二倍，

但這很難去跟主管溝通，造成導入Pair Programming的難度。

實作作法與心得

我是在帶菜鳥的情況下引進這套方法的，而且在執行上效果也還不錯，下方是作法與心得給大家參考：

我（老鳥）與新人（菜鳥，剛畢業，第一份工作）配成一對，使用一台電腦，看相同的畫面，每15分鐘交換一次角色。

而當我在當Driver（駕駛者）時，我會在寫程式的同時，如果這一段程式比較困難，我就會邊寫邊問：「這樣看得懂嗎？」，並且鼓勵菜鳥，看不懂一定要問；

而當菜鳥看不懂時，我會停下程式，花時間跟他解說，而解說的時間也算在15分鐘內；所以有可能我只花了5分鐘在寫程式，十分鐘在講解程式。

而當我在當Observer （觀察者）的時候，我會觀察菜鳥的程式，從中也可以知道他們的思考是不是對的？程式上該如何寫才會更好？

在交談中如果發現有些觀念需要調整，我也會請他停下寫程式的手，教導他如何作才是對的，或者教導他如何寫才會更好，而這些時間也包含在他的15分鐘內。

雖然這樣導致產出降低了，不過當這樣子在帶新人時，新人會學習：

1. 部門使用的各類工具，像是Git、IDE之類的。
2. 商業邏輯的理解，每個專業（例如：醫療、建築）都會有各自的商業邏輯，而這些商業邏輯也是新人要花時間學的。
3. 程式能力的提升，因為老鳥會教導在這種情況下如何去寫程式才正確，所以菜鳥的程式能力也會提升。

而老鳥在這種狀況下則是學習如何帶人、如何溝通。

通常這樣子帶下來，大約一～二個月的時候，菜鳥就可以獨立去寫簡單的程式了；

而這種時候，筆者的三分鐘熱度也降下來了（想偷懶了），所以又回到單兵作業的模式去了。

建議

上方描述的是筆者個人的經驗與心得，最後給想要引進這種方法的人一點建議，所有的方法都要視情況而使用，而非一味的強行套用，

筆者建議在以下情況時，可以試著引進Pair Programming來試看看：

• 當有新人進來時，想以On Job Training的方法帶起新人的話，不如改為Pair Programming。

因為菜鳥在一個陌生的地方，要去打擾工作中的老鳥還是會有心理負擔的，不如套用Pair Programming，

這樣老鳥的工作會變成除了原有的程式工作外，引導菜鳥也會變成老鳥的工作，而菜鳥因為與老鳥在看相同的畫面，也比較容易知道要在什麼時候打斷老鳥，

這種狀況下的心理負擔也會比較小。

• 複雜的邏輯時，也可以試著套用。

複雜的邏輯當然比較容易出Bug，因此，若套用Pair Programming的話，邏輯會比一個人去思考更清晰，並且複雜的商業邏輯當然會引出複雜的程式，

而複雜的程式在理解與交接上會更麻煩，但套用Pair Programming的話，在完成工作時，就至少有二人是瞭解程式的，

這樣對專案與個人來說，負擔都比較少。

有合適的情況，當然也有不合適的情況，下方的情況是不適合套用Pair Programming的情況：

• 專案的在趕時程的情況：Pair Programming的優點是能產生Bug較少的程式，但花費的工時的確會比單人多，所以若專案在趕時程的話，不建議套用。
• 外務較多的情況：當兩人中的一人，外務比較多的時候（容易被其他事中斷的時候），因為中斷的時間是兩個人共通的時間，所以當一個人在處理他的外務時，Pair Programming就不成立了，如此，不如回到單兵作業的方式去還較有效率。
• 想偷懶的時候也不建議，原因跟外務較多的情況是一樣的喔

這些感想是在公司三年多，當中套用了兩～三次Pair Programming的感想，供大家參考。