談談 Pair Programing —下班有約系列文

前幾天跟一位給了我很多幫助的學長一起吃晚餐，因為同為資訊工程領域，所以聊天的話題也不免轉移到程式方面；其中談到 Pair Programing 的話題時，我覺得學長的見解很棒，因此趁記憶猶新時記錄下來，也許未來筆者也會在自己的公司試行看看。

文章大綱
一、 Code Review 這件事
  ➤ 時機點
  ➤ 由誰來 Review？
二、 網頁一開始並沒有前後端之分
  ➤ 在過去，每個人都是全端
  ➤ 分前後端，是為讓專業更專業
  ➤ 網頁工程師應該都要是全端
三、 談談 Pair Programing
  ➤ 什麼是 Pair Programing？
  ➤ 更好的 Code Review 機制
  ➤ 讓團隊每個人都變成全端
  ➤ 可能會遇到的問題

一、 Code Review 這件事

時機點

筆者通常是在 Git Commit、Merge Request 的時機去做 Code Review 這件事，因為過去做的習以為常，所以沒有去思考這樣做到底有沒有意義。

跟學長討論的過程中，我們發現在這個時間點做 Code Review，往往只能看到很片面的程式邏輯，因此通常僅能對 Coding Style 提出建議，對整體專案的架構幫助並不大；而且通常只有在新同事入職時會認真看，過一段時間後就會放鬆然後隨便了。

由誰來 Review？

往往是由在公司待比較久的資深工程師來做這件事情，從邏輯上看起來沒有什麼問題；但實際上資深工程師給出的建議，在很多時候新人是無法理解原因的，他只是根據建議做修改，並沒有了解為什麼要這樣做，所以下次可能還是會犯相同的錯誤。

我們不能期待一個新人在剛入職時，就有向前輩提出問題、追根究底的勇氣；但前輩看到他一再犯下相同的錯誤時會去想：「我不是已經交了他很多次了，為什麼還是學不會？」

如果讀者也有相同的經驗，也許我們自己要做一些調整。

---

二、 網頁一開始並沒有前後端之分

在過去，每個人都是全端

在十幾年前，網頁並沒有明確的將工作劃分成前後端，當時的工程師基本上同時具備網頁切版、資料庫設計、伺服器架設…等技能。

分前後端，是為讓專業更專業

隨著網頁技術的蓬勃發展，每年都會推出大量的新技術，一個工程師很難在各個領域都即時跟上；也因此工作的內容有更明確的劃分，像是前後端分離、Devops、UIUX…等概念與技術也應運而生。

網頁工程師應該都要是全端

無論工作的內容是前端還是後端，筆者個人認為都應該要具備全端的知識水平；你不用在全部領域都做到專家的等級，但至少你要能夠看得懂對方寫的 Code，並具備基礎的維護能力。

---

三、 談談 Pair Programing

什麼是 Pair Programing？

這是雙方看同一個螢幕，經過彼此交流來共同開發的一個機制；筆者曾經寫一篇文章說明過去 Pair Programing 遇到的問題、有什麼工具可以讓我們在 Pair Programing 有更高的效率，有興趣的朋友可以參考：連結。

更好的 Code Review 機制

比起等對方寫好後來做 Code Review，Pair Programing 可以更即時的知道對方是從哪個角度出發來寫這個程式的。

剛入職的同事如果是透過 Pair Programing 來做開發，他可以更快速地融入團隊，並在短時間內將技術提升至團隊平均開發水平；這個過程中前輩也能對新人的技術有更高的掌握度，並作出合適的提點。

讓團隊每個人都變成全端

在談話的過程中，學長認為前後端的劃分雖然有必要；但不管是前端還是後端，應該都要具備全端的能力，因此我向學長問道：「可是很多人就是以前端/後端工程師的身份入職，他們真的對另外一個領域完全不熟悉啊；先不論他們是否願意學習，就算願意學習，他們手上的專案也會 Delay，這些成本也要納入考量吧？」

關於這個問題，學長的觀點是這樣的：「不管前後端，程式的邏輯都是一樣的，只是應用的地方不同而已；學習的成本一定有，但沒有你想像的那麼高，原則上 1 個禮拜就能夠具備基礎的開發能力；先跟老闆溝通好，專案 Delay 一個禮拜沒你想的那麼嚴重。」

聽到變成全端的時間成本，我真的不太理解為何會這麼短，於是我拋出問題：「一個禮拜？不可能吧？這怎麼可能做到？有更具體的做法嗎？」

面對我的質疑，學長回答是：「我這邊是用 Pair Programing 達成的，兩個工程師輪流寫，強迫他跨出舒適圈；這個舒適圈一但跨出，旁邊又有一個可以隨時解惑的老師，相信我，人類的學習潛能遠比你認知的還要強大。」

上面是學長在自己公司實踐的成果，筆者尚未在自己的公司實踐；但我相信這個作法一定可以提升團隊整體的程式水平以及歸屬感。

可能會遇到的問題

1. 沒有合適的教練
   就算有工程師願意學，也需要團隊裡面有人願意一起陪練；最佳的陪練就是「資深全端工程師」，因為他前後端都懂，所以在面對問題時可以更全面地給出解答，但能做到並願意這樣做的人，市場上應該不會太多。
2. 時間成本、成效因人而異
   每個人的資質與領悟力不同，對原本領域的鑽研深度也不一樣；這些個體化的差異可能會讓你在推行這個政策的時候結果不如預期。

---

文章僅是提出不同的觀點以及作法，是否適合自己的團隊、具體如何導入；筆者認為需要自己去評估，如果你有自己的想法或不同的見解，也歡迎在底下留言。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing(本篇)
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！