談談軟體開發 - Pair Programming
會談這個主題主要是工作上預計進行Pair Programming的模型來開發，因而蒐集了一些關於Pair Programming這方面的相關概念與執行方向，並整理讓大家共同參考、討論。
但實務上真的可行嗎？ 老闆同意嗎？ 在執行前個人心中的兩大疑問，那麼以底下例子來看，這個問題的確沒有絕對的答案，取決於我們的思考面向。
如果大家認同航船過程中要有船長及副船長才足夠安全，那麼Pair Programming就是這樣的保險概念，透過雙人合作、互補來保障乘客順利抵達目的地，套用到產品的開發上也是如此，雖然兩個人共同做一件事情看似很蠢，但後續的經濟效益通常是我們沒有考慮的部分，試想我們的產品如果品質不好，在客戶端老是出包，那麼相信維護人員只會疲於奔命，對公司無非是莫大的損傷，產品給客人的觀感也不佳，影響公司的名聲，只要這樣的聲量傳開來，相信競爭者看到也一定很開心吧! 我想這並非公司所樂見的，因此Pari Programming就成為了這問題的解方之一，除了改善品質之外，還能用來進行新人訓練，甚至新產品研發都是非常適合的模式。
總之，取決於我們看事情的角度，假若我們重視的是後續的維護成本及產品品質，那麼Pair Programming就非常適合導入，但若僅是為了短期專案，只要快速結案就好，那麼用Pair Programming就多此一舉了，接著就直接進入主題吧！
Pair Programming是軟體領域中經典的開發方法，源自於極限編程的一種方法，又稱為結對編程，白話來說就是兩個人一起寫Code或者是完成某項指標任務，共同合作、互補、創新，主要會由以下兩個角色組成，分別是導航者(Navigator)跟駕駛者(Driver)，導航者負責觀察、規劃及回饋，而駕駛者負責實際執行。
過程中2位工程師會用同一台電腦，針對同一支程式進行開發，上圖中每個人都可能是導航者與駕駛者，因為可以互相交換角色，以不同觀點來發掘問題與提出解決方法，減少單獨開發的盲點，提升產品品質。
🔔還沒成為Potato會員的朋友點這裡加入哦，增加知識還能挖礦打造被動收入 🔔
優點
俗話說獨樹不成林，單打獨鬥難以成事，一個人寫程式想必存在許多盲點，而這個盲點如果有另一個人一起檢視，那麼或許問題就更容易被發現，也減少在正式環境上發生BUG的機會，但如果讓兩個工程師做一樣的事情卻沒有任何優點與回報的話，任何老闆都不會買單的，因此我們需要探討，Pair Programming究竟能帶給我們哪些優點呢？ 以下整理幾個重點：
提升程式碼品質
協作的過程相當於多了一個人幫我們檢視程式碼，發現問題立刻就能夠修復，一但BUG數量減少，意味著QA的測試成本及後續維護成本也隨之減少，因此有效的Pair Programming能夠讓程式碼品質變的更好。
知識的學習和共享
雙方的認知上有所不同，因此過程中可以互相提出疑問和看法，並在即時的討論過程中激盪出新的解決方案，共同互補。
舉例來說，解決問題的演算法可能有多種，那麼假設今天獨自開發時，可能直覺的以過往經驗寫出一套自認完整的演算法，但透過第三者的檢視之後，或許對於原本的演算法能夠有新的想法，透過彼此討論後，又能產生一套效能改進後的演算法，但若沒有這種激盪的過程，或許自己就陷入了迷思之中，也難以產生創新的解決方案。
雙方在交換資訊的同時，也達到了知識共享的成果，透過這樣持續的合作，讓學習事半功倍，除此之外還會訓練彼此的溝通能力，因為我們需要跟搭檔相互溝通，以對方能理解的語言解釋，進而提升軟實力。
提升團隊效率
團隊中通常每個人都會負責一塊產品獨立的模組，假設某個功能模組的成員請假、離職時，若平常沒人熟悉該模組時，就沒有人可以接手了，那麼若專案時程又是非常急迫時，勢必對於團隊造成非常大的衝擊，效率也隨之延宕。
透過Pair Programming讓某項功能模組都至少有兩個人熟悉，專案忙碌時至少有人可以互相Cover，對於團隊以及公司都是百利無一害。
缺點
專案工時增加
兩個人共同開發相同的部分，那麼工時計算就會增加為2倍，這在老闆眼中顯然不是非常樂觀的開發方式，但增加的工時，若Pair Programming能夠有效的發揮成效，則增加的工時會在「減少的BUG」、「工作互補性」這兩塊拿回來。
消耗專注力
由於經常討論，因此容易導致開發到一半的過程中被打斷，造成專注力下降，因此一周選定幾天進行即可，不需要每天執行，否則反而帶來反效果。
如何執行？
選定目標與任務
- 將大任務切成小任務。
- 設定到期日，於期間內短期衝刺。
成員挑選
- 一個資深一個資淺，切忌兩個不懂的新人共同進行，導致無效率行為。
- 兩個理念不合，經常吵架的成員最好不要共同進行，避免耗費時間與精神在處理情緒上。
定期交換角色
- 活化思緒，避免僵化。
- 換位思考，以不同角色觀察不同面向。
- 激盪想法，創造解決方法。
- 減少盲點。
注意事項
- 團隊不一定要採取指派的方式進行，而是有需求就可以進行結對，發揮敏捷開發的精神。
- 當夥伴與自己已經趨近熟悉、未能再有更多突破時，就可以考慮先停止，或者重新結對。
- 過程中應理性討論，而非互相仇視、指責、批評。
🔔還沒成為Potato會員的朋友點這裡加入哦，增加知識還能挖礦打造被動收入 🔔
書籍推薦
如果您正在為了專案效率而努力，或者想要了解更多關於敏捷開發的相關知識，非常推薦「SCRUM敏捷實戰手冊」，讓我們一起變強，學習更多不同領域的知識吧！