今天要聊的議題我覺得很有趣，叫做 Par Programming。關於這議題我的經驗也沒有很豐富，但就姑且分享作為拋磚引玉吧。這邊我嘗會試用自己的認知來解釋，或許對這個名詞的定義會比較寬鬆。

Pair Programming，簡單來說就是兩個人聚焦在同一個電腦畫面，針對同一支程式一起編寫。由於自己本身也是遠端工作者，所以我不會特別強調一定要做在一起，或是通常只能由一個人操作，畢竟這比較偏向物理上的限制。我認為重點是兩人聚焦在同一個程式開發的同一個畫面上，一起討論與開發，過程中可以兩個人都有自己的鍵盤，就像是在協作編寫 Google Docs 一樣，邊討論邊完成這程式。

我們自己一個人在寫程式的當下，其實很容易在編寫時突然停下來思考某個問題，想完之後再繼續編寫。在思考時，通常就是不斷的在拋出問題給自己去想，像是「這邊採用 if-else 寫法會不會違反開放封閉原則，改成 XXXX 是不是會比較好，但是有必要在現階段去實作嗎？」、或是「這個資料庫與模型的關聯設計是不是當下最適合的關係？我是不是還有漏掉什麼？」諸如此類的問題。運氣好的話，我們可能停頓個一下，就得出結論繼續寫；倘若狀況不好的話，可能就會陷入鬼打牆，或是雖然感覺腦袋在思考，但事實上思路壓跟兒沒有前進。

或是我們在寫程式時，偶爾想得太直接時，寫出來的程式可能沒有考慮到某些潛在的原因，就直接寫下去了。等到 Code Review 甚至產品上線發生某些問題時，才會發現自己當初考慮得太淺了，但是可能損失已經造成了。

可能還有更多情境可以去描述一個人寫程式時，可能會遇到的問題，這邊就嘗試以這兩個方向來聊聊。

當我們寫程式在思考問題，或是遇到鬼打牆時，這時候若是有個人能直接與你對話，就能明確的把腦海中的問題陳述出來，或許再把問題陳述出來的過程中，就又有新的想法迸出。如此，讓雙方的多個想法碰撞，一旦思緒就會來有來自外部的資訊，讓我們能夠更活躍的思考，甚至因為有夥伴與你對話而激發出更多想法，降低鬼打牆的無助情況。

或是當一個人在編寫程式時，另一個人從旁觀摩時，就會嘗試去理解編寫者這樣想是為了什麼，思考他那段程式碼的用意。若是無法猜出用意，可能就是編寫者在可讀性上要再加強，也有可能是編寫者在做法上和旁觀者不太一樣，兩邊因為想法不同，所以礙於出發點不同導致無法理解，這時候旁觀者若是即時提出疑問，編寫者可能就會意識到自己在做法上可能有沒想到的部分，而在去進一步思考。或是在嘗試解釋的過程中，發現其實自己也解釋不太出來，那可能就有問題。

從這兩個方向可以看出 Pair Programming 一些好處，而且也能透過這種方式讓程式碼不會只有一個人懂，從而降低產品維護因為一個人缺席導致無法進型的風險。

隨著更多編輯環境的資源被開發出來，現在想在編輯器上建立起類似 Google Docs 協作模式已經不是難事了 [^1]。我們可能會看到兩個游標在畫面上，得以即時切換編寫者方便討論與詢問。也就是 Pair Programming 的物理限制與技術門檻其實是降低的，所以我認為可以開始在某些時候嘗試看看，或許你也會發現上面提到的好處，或是享受到更多的回饋。

1: 例如可使用 Visual Studio Live Share。