什麼是 Pair Programming？

通俗的定義就是雙方看同一個電腦（或是螢幕分享），一個人寫程式（駕駛員），另一個人審查他寫的每一行程式（觀察員）。

觀察員提供戰略方向，駕駛員專注執行戰術，透過即時的交流解決問題，並寫出更好的程式。

一個人寫程式容易有「盲區」，多一個人在旁邊可以有更廣闊的視野。

用 Pair Programming 讓新人成為即戰力

我們希望新人可以在入職後可以快速掌握專案，並對團隊做出貢獻；為了這個目標，每份專案的技術文件都非常重要，它可以大幅減少新人熟悉專案的時間。

但無論文件寫得多麼詳細，新人在開發時總是會遇到一些狀況，比如：

1. 因為對專案不熟悉，導致開發時有「重工」的現象（ex：沒使用既有函式，而是自己撰寫新的函式）。
2. 對功能的運算邏輯不夠瞭解，在「重構」的過程中，把原本的演算法改壞了。
3. 不熟悉專案現在使用的框架，導致「用很複雜的方式」去完成框架已經內建的功能。

上面所提到的這些問題，其實透過 Pair Programming 都能有效改善；在新人剛入職時，可以安排一個資深工程師透過 Pair Programming 了解新人寫程式時的想法，並對完成的部分做 Code Review，盡可能把問題扼殺的萌芽，並加速新人對環境的熟悉。

用 Pair Programming 培養全端

我有個朋友曾提出一個很棒的理念，他說：「在職位上區分前、後端，但在能力上希望每個人都是全端。」

其實不管前後端，在程式上面的邏輯都是通用的，只是應用的地方不同。

Pair Programming 亦可用於培養全端人才，在實際執行上，前端與後端為一組，輪流寫對方要完成的功能；因為遇到問題隨時有人可以詢問，因此可以快速了解新領域該注意的種種要點。

這麼做的目的並不是要讓你成為該領域的專家，而是培養工程師的「視野」，讓你更了解系統的整體架構。

按照上面的方法就能培養全端嗎？

團隊中每個成員的人格特質不同、工作目標不同，在推行前一定要先評估每個人的意願，否則強制推行只會造成反效果；建議先讓一部分有意願的人先執行看看，觀察成效。

即使團隊成員樂於參與，但每個人的資質與領悟力不同，對原本領域的鑽研深度也不一樣，因此推行的人要注意：「不要用統一的標準來衡量每個人的進步。」

文章僅是提出不同的觀點以及作法，是否適合自己的團隊、具體如何導入，筆者建議要謹慎評估。

想跟大家聊聊

不知道大家在工作中是否有用過 Pair Programming？在使用的過程中有遇過哪些阻礙與問題？可以在底下留言分享自己的感想喔！

如果你是第一次接觸 Pair Programing，在看完這篇文章後會想要在自己的團隊嘗試看看，或是推薦給主管嗎？

如果有自己的想法或不同的見解，歡迎留言一起討論喔！

大綱
➤ 可以一起遵守的 Coding Style
➤ 使用相同的程式碼 Format 工具
➤ 沒有明確 Git Flow 機制會發生什麼事？
➤ 制定團隊 Git Flow 的規則

可以一起遵守的 Coding Style

即使是有經驗的工程師，在同一個專案中也很常不小心有多種命名的風格，下面列出幾個建議：

• 變數與函式：都用小駝峰式（camelCase）的命名，ex：downloadDoc、deleteDoc。
• 常數命名：會建議使用全大寫英文命名，字詞間使用下底線（_）連接，ex：VUE_APP_ROOT_API。
• 少用簡寫或自己發明縮寫：就算是本人，幾個月後也會忘記自己當時創造的東西。
• 不要拼錯英文單字：當程式結構越來越大，我們會透過搜尋來找答案，如果你拼錯就會造成大家的困惑。
• 字串單引號、雙引號統一：儘管在 JavaScript 中兩者皆可運行，但在閱讀體驗上就會有點不舒服。

使用相同的程式碼 Format 工具

其實上面的問題大部分可以透過「工具」來解決，但必須律定團隊使用「統一」的工具。

如果團隊沒有統一的工具，會導致你每次在更新專案時，明明只更新一行，但因為每個人 Format 工具不同導致在 Merge Branch 時看起來幾乎是重寫。

這邊推薦使用 VSCode Extensions 的 Prettier，他支援大部分程式語言的 Format；當然知名的 ESLint 也是團隊協作時的好選擇。

不同 Format 工具的斷行字數、單引號、雙引號、結尾有沒有「;」…的習慣都不一樣，如果大家不統一，你看 diff 時會覺得很崩潰並且浪費時間。

沒有明確 Git Flow 機制會發生什麼事？

如果沒有一套基礎簡單的規則，你可能會遇到以下障礙：

• Deploy（部署）沒有基準：正式機、測試機要用哪個 Branch？如果每次都不一樣，那遲早都會出事。
• 花很多時間在 Merge Branch（合併分支）上：如果不是從同一條 Branch 分支出去，那在 Merge 時很容易出現各種衝突需要解決。
• 難以從 Branch 追蹤作業進度：有些人會只用一條 Branch 從頭做到尾，造成單純看這個分支無法理解他到底完成了哪些功能。
• 無法理解的 commit 內容：每個人都有自己的 commit 風格，導致追溯歷史時很難找到節點。
• 任務交接時的困擾：有些人沒有定期 push 的習慣，喜歡累積非常多的 commit 再一次 push；這樣如果他突然請假，或剛好在忙其他事情時，職務代理人並無法協助處理他的任務，甚至重工浪費時間。

制定團隊 Git Flow 的規則

下面是筆者團隊在各個 Branch 的規則：

🏷️ Master

• 功能：部署到正式機的 branch
• Merge request：由資深工程師或是技術主管審核

🏷️ Develop

• 功能：部署到測試機的 branch
• Merge request：由資深工程師或是技術主管審核

🏷️ Feature

• 命名方式：依功能命名，如果有任務編號的話一同附上，方便日後追蹤
• 基礎規則：原則上都是從 Develop 分支出去，每個 Feature 的功能盡量細分到可以在一天內完成

🏷️ Hotfix

• 命名方式：依功能命名，如果有任務編號的話一同附上，方便日後追蹤
• 基礎規則：原則上是為了解決正式機上面的緊急 Bug，因此通常是從 Master 分支出去；完成修改後再合併回 Master、Develop

🏷️ Release

• 命名方式：依釋出的版本命名
• 基礎規則：當有一個大版本準備部署到正式機，為了保證系統穩定性，會先從 Develop 分支 Release 的版本

以及其他希望大家一起遵守的細節：

• 完成 Feature 時要 push 一版，並通知協作夥伴確認功能。
• 如果該 Feature branch 已經 merge 回 develop，且不會再使用該 branch，就需要把它給 delete 掉，避免線上有太多分支，會不清楚哪一個才是有在作用的。
• 每天下班前至少要 push 一版，讓管理者容易掌握進度。
• commit 可以用「新增功能、變更功能、修補 Bug」作為 title 的分類，然後將調整的內容條列式寫入 description，這樣其他人在 Code Review 時可以知道重點，範例如下：

### title
修補 Bug：解決職員列表 issues
### description
1. 解決排序無效 bug
2. 在「異常」欄位增加是否為 null 的判斷，避免字串切割異常
3. 解決 pagination 參數沒有傳送到的問題

筆者認為「簡單、易懂」為第一優先，中英文表達都可以。

相信還有很多可以讓開發團隊協作更愉快的工具與方法，期待大家的留言分享～

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

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

文章大綱
一、 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 不想告訴你的秘密！

一、我們現在協作時遇到了哪些困境？
二、這個工具能給我們開發帶來什麼樣的幫助？
三、安裝套件＆登入使用者
四、使用方式

一、我們現在協作時遇到了哪些困境？

• 使用螢幕分享做 Debug 時，需要依靠大腦來做運算邏輯，想要看哪一支檔案與程式也要靠口述，非常不方便
• 有些程式（Teams），不只螢幕分享來能直接控制對方的電腦做操作，但同一時間只允許一人做操作
• 就算團隊使用 git 版控，你切到對方有 Bug 的 branch 時可能無法順利重現問題發生（很多套件版本及環境參數設定不同）
• 因為無法完全模擬對方程式運作環境導致 Debug 時困難重重

二、這個工具能給我們開發帶來什麼樣的幫助？

• 對方能夠很清楚理解自己現在講述的程式在哪個檔案的哪個位置，不再雞同鴨講
• 雙方能自由瀏覽專案下的資料夾與程式，無需依靠口述
• 可以模擬對方的環境進行程式編譯，更清楚問題發生點
• 雙方的游標顏色不同，方便討論時不會產生誤會

三、安裝套件＆登入使用者

下面的步驟及操作可能會隨著 VScode 改版而有所不同，僅供參考

SETP 1：在 VScode 的 EXTENSION 分頁搜尋「Live Share」，點擊「install」即可完成安裝

SETP 2：安裝完後會在左下角多出「LIVE SHARE」的icon

SETP 3：第一次按「Share」時，會要求你登入 GitHub 或是 Microsoft 的帳號

SETP 4：這裡我選擇登入Github，基本上就是一路按接受授權的過程

SETP 5：註冊成功後，你就會看到以下畫面

四、使用方式

完成安裝＆登入的步驟後，下面提供本機模擬的操作方式

自己跟自己的連線，模擬操作

SETP 1：在本機用 VScode 開啟一個資料夾或是專案

SETP 2：點擊「Share」做分享，此時你會得到一組邀請連結

SETP 3：此時開用「New Windows」開啟一個空的 VScode，點擊「Join」加入

SETP 4：加入後加入後便可以開始共同開發嚕

當 Join 的人對檔案操作時，Share 的人可以看到他的操作

了解 Share 的人跟 Join 的人正在操作的畫面

按下右上角的「圖釘」，就是「Follow Participant」觀看對方現在操作的檔案

直接在對方的環境下執行程式了解問題

Join的人可以直接在終端機下指令，了解程式執行狀況

本篇文章只是很簡略地讓大家了解如何使用「Live Share」這款套件，更多的功能就讓大家直接去官網了解吧！