談談軟體開發 - Pair Programming
會談這個主題主要是工作上預計進行Pair Programming的模型來開發，因而蒐集了一些關於Pair Programming這方面的相關概念與執行方向，並整理讓大家共同參考、討論。
但實務上真的可行嗎？ 老闆同意嗎？ 在執行前個人心中的兩大疑問，那麼以底下例子來看，這個問題的確沒有絕對的答案，取決於我們的思考面向。
如果大家認同航船過程中要有船長及副船長才足夠安全，那麼Pair Programming就是這樣的保險概念，透過雙人合作、互補來保障乘客順利抵達目的地，套用到產品的開發上也是如此，雖然兩個人共同做一件事情看似很蠢，但後續的經濟效益通常是我們沒有考慮的部分，試想我們的產品如果品質不好，在客戶端老是出包，那麼相信維護人員只會疲於奔命，對公司無非是莫大的損傷，產品給客人的觀感也不佳，影響公司的名聲，只要這樣的聲量傳開來，相信競爭者看到也一定很開心吧! 我想這並非公司所樂見的，因此Pari Programming就成為了這問題的解方之一，除了改善品質之外，還能用來進行新人訓練，甚至新產品研發都是非常適合的模式。
Pair Programming是軟體領域中經典的開發方法，源自於極限編程的一種方法，又稱為結對編程，白話來說就是兩個人一起寫Code或者是完成某項指標任務，共同合作、互補、創新，主要會由以下兩個角色組成，分別是導航者(Navigator)跟駕駛者(Driver)，導航者負責觀察、規劃及回饋，而駕駛者負責實際執行。
過程中2位工程師會用同一台電腦，針對同一支程式進行開發，上圖中每個人都可能是導航者與駕駛者，因為可以互相交換角色，以不同觀點來發掘問題與提出解決方法，減少單獨開發的盲點，提升產品品質。
優點
俗話說獨樹不成林，單打獨鬥難以成事，一個人寫程式想必存在許多盲點，而這個盲點如果有另一個人一起檢視，那麼或許問題就更容易被發現，也減少在正式環境上發生BUG的機會，但如果讓兩個工程師做一樣的事情卻沒有任何優點與回報的話，任何老闆都不會買單的，因此我們需要探討，Pair Programming究竟能帶給我們哪些優點呢？ 以下整理幾個重點：
提升程式碼品質
協作的過程相當於多了一個人幫我們檢視程式碼，發現問題立刻就能夠修復，一但BUG數量減少，意味著QA的測試成本及後續維護成本也隨之減少，因此有效的Pair Programming能夠讓程式碼品質變的更好。
知識的學習和共享
雙方的認知上有所不同，因此過程中可以互相提出疑問和看法，並在即時的討論過程中激盪出新的解決方案，共同互補。
舉例來說，解決問題的演算法可能有多種，那麼假設今天獨自開發時，可能直覺的以過往經驗寫出一套自認完整的演算法，但透過第三者的檢視之後，或許對於原本的演算法能夠有新的想法，透過彼此討論後，又能產生一套效能改進後的演算法，但若沒有這種激盪的過程，或許自己就陷入了迷思之中，也難以產生創新的解決方案。
雙方在交換資訊的同時，也達到了知識共享的成果，透過這樣持續的合作，讓學習事半功倍，除此之外還會訓練彼此的溝通能力，因為我們需要跟搭檔相互溝通，以對方能理解的語言解釋，進而提升軟實力。
提升團隊效率
團隊中通常每個人都會負責一塊產品獨立的模組，假設某個功能模組的成員請假、離職時，若平常沒人熟悉該模組時，就沒有人可以接手了，那麼若專案時程又是非常急迫時，勢必對於團隊造成非常大的衝擊，效率也隨之延宕。
透過Pair Programming讓某項功能模組都至少有兩個人熟悉，專案忙碌時至少有人可以互相Cover，對於團隊以及公司都是百利無一害。
缺點
專案工時增加
兩個人共同開發相同的部分，那麼工時計算就會增加為2倍，這在老闆眼中顯然不是非常樂觀的開發方式，但增加的工時，若Pair Programming能夠有效的發揮成效，則增加的工時會在「減少的BUG」、「工作互補性」這兩塊拿回來。
消耗專注力
由於經常討論，因此容易導致開發到一半的過程中被打斷，造成專注力下降，因此一周選定幾天進行即可，不需要每天執行，否則反而帶來反效果。
如何執行？
選定目標與任務
- 將大任務切成小任務。
- 設定到期日，於期間內短期衝刺。
成員挑選
- 一個資深一個資淺，切忌兩個不懂的新人共同進行，導致無效率行為。
- 兩個理念不合，經常吵架的成員最好不要共同進行，避免耗費時間與精神在處理情緒上。
定期交換角色
- 活化思緒，避免僵化。
- 換位思考，以不同角色觀察不同面向。
- 激盪想法，創造解決方法。
- 減少盲點。
注意事項
- 團隊不一定要採取指派的方式進行，而是有需求就可以進行結對，發揮敏捷開發的精神。
- 當夥伴與自己已經趨近熟悉、未能再有更多突破時，就可以考慮先停止，或者重新結對。
- 過程中應理性討論，而非互相仇視、指責、批評。
書籍推薦
如果您正在為了專案效率而努力，或者想要了解更多關於敏捷開發的相關知識，非常推薦「SCRUM敏捷實戰手冊」，讓我們一起變強，學習更多不同領域的知識吧！
即將進入廣告，捲動後可繼續閱讀
為什麼會看到廣告
118會員
263內容數
哈囉，我是阿Han，是一位 👩💻 軟體研發工程師，喜歡閱讀、學習、撰寫文章及教學，擅長以圖代文，化繁為簡，除了幫助自己釐清思路之外，也希望藉由圖解的方式幫助大家共同學習，甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
你可能也想看
Google News 追蹤
Pair programming，譯為「結對編程」，是敏捷軟體開發的一種方式，由兩位軟體工程師同時開發一個程式，簡單來說，原本一個人可以完成的工作，找了兩個人來做，人力成本直接變成兩倍！
｜本篇報導同步刊登於 科技島
在大量運用 AI 人工智慧的時代，為何外商軟體公司仍積極運用結對編程進行
親愛的讀者
感謝你提出這個富有挑戰性且極具時代感的問題。程式設計，這門技術宛如一把打開數位世界的鑰匙，讓人得以探索無限的可能性。在這個科技日新月異的時代，程式設計的魅力不僅僅在於其實用性，還在於它能夠改變我們看待問題和解決問題的方式。
然而，你提問的核心不僅是程式設計本身，而是它是否能成為你
親愛的讀者
感謝你提出這個問題。這是一個現代社會中很常見且重要的疑惑。隨著科技的迅猛發展，程式設計似乎成了人人必備的技能，讓許多人產生了焦慮和壓力。讓我們從多個角度深入探討這個問題，希望能為你解答心中的疑惑，並提供實用的建議。
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
在日常生活和工作中，我們經常需要與人合作，無論是小規模的合作還是大型團隊的合作。良好的合作關係能提高效率、增強創造力。但為什麼很多時候，我們寧願單打獨鬥，都不想與人合作呢？今天我們來聊聊這個話題。
這個系列的文章主要專注於物件導向到函數式編程的差異與分析，並針對概念與機制上的不同進行比較。很多人說物件導向和函數式編程沒有哪個比較好的問題，只有哪個比較適合的問題，然而我並不這麼認為，我透過這一系列的文章從各個角度討論它們之間的優缺點就是為了闡述我的觀點。物件導向錯在沒有理論基礎，但它贏在熟悉性，
同船共渡何彼此 飆風驚浪明燈尋
中路暢行左右迷 彈冠有信相提攜 磽磽易缺韜光好 萬事相忍勿唐突
同船共渡何彼此，是在描述所看到的現象。 就看到的現象而言，因為分別心的作祟，造成彼此溝通有閉塞的現象，而形成阻礙。這會讓團隊的整體運作，失去功能，如果可以多多溝通，而轉換這樣的形態，才可以有所成就。
學會如何建立合作關係和協作完成任務，是在現實職場中很重要的能力。 書本提到了一些觀點，協作對象不該一視同仁，一個偏好獨立工作的軟體工程師，要如何與一位合作型的產品經理一起協作開發一個新功能？一個協調型的培訓人員，如何和一個獨立型的老師協作改善教學品質？書中的案例或許能幫你思考這些問題的答案。
Pair programming，譯為「結對編程」，是敏捷軟體開發的一種方式，由兩位軟體工程師同時開發一個程式，簡單來說，原本一個人可以完成的工作，找了兩個人來做，人力成本直接變成兩倍！
｜本篇報導同步刊登於 科技島
在大量運用 AI 人工智慧的時代，為何外商軟體公司仍積極運用結對編程進行
親愛的讀者
感謝你提出這個富有挑戰性且極具時代感的問題。程式設計，這門技術宛如一把打開數位世界的鑰匙，讓人得以探索無限的可能性。在這個科技日新月異的時代，程式設計的魅力不僅僅在於其實用性，還在於它能夠改變我們看待問題和解決問題的方式。
然而，你提問的核心不僅是程式設計本身，而是它是否能成為你
親愛的讀者
感謝你提出這個問題。這是一個現代社會中很常見且重要的疑惑。隨著科技的迅猛發展，程式設計似乎成了人人必備的技能，讓許多人產生了焦慮和壓力。讓我們從多個角度深入探討這個問題，希望能為你解答心中的疑惑，並提供實用的建議。
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
在日常生活和工作中，我們經常需要與人合作，無論是小規模的合作還是大型團隊的合作。良好的合作關係能提高效率、增強創造力。但為什麼很多時候，我們寧願單打獨鬥，都不想與人合作呢？今天我們來聊聊這個話題。
這個系列的文章主要專注於物件導向到函數式編程的差異與分析，並針對概念與機制上的不同進行比較。很多人說物件導向和函數式編程沒有哪個比較好的問題，只有哪個比較適合的問題，然而我並不這麼認為，我透過這一系列的文章從各個角度討論它們之間的優缺點就是為了闡述我的觀點。物件導向錯在沒有理論基礎，但它贏在熟悉性，
同船共渡何彼此 飆風驚浪明燈尋
中路暢行左右迷 彈冠有信相提攜 磽磽易缺韜光好 萬事相忍勿唐突
同船共渡何彼此，是在描述所看到的現象。 就看到的現象而言，因為分別心的作祟，造成彼此溝通有閉塞的現象，而形成阻礙。這會讓團隊的整體運作，失去功能，如果可以多多溝通，而轉換這樣的形態，才可以有所成就。
學會如何建立合作關係和協作完成任務，是在現實職場中很重要的能力。 書本提到了一些觀點，協作對象不該一視同仁，一個偏好獨立工作的軟體工程師，要如何與一位合作型的產品經理一起協作開發一個新功能？一個協調型的培訓人員，如何和一個獨立型的老師協作改善教學品質？書中的案例或許能幫你思考這些問題的答案。