談談軟體開發 - 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敏捷實戰手冊」，讓我們一起變強，學習更多不同領域的知識吧！
為什麼會看到廣告
120會員
270內容數
哈囉，我是阿Han，是一位 👩💻 軟體研發工程師，喜歡閱讀、學習、撰寫文章及教學，擅長以圖代文，化繁為簡，除了幫助自己釐清思路之外，也希望藉由圖解的方式幫助大家共同學習，甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
你可能也想看
Google News 追蹤
在創作的路上真的很多人問我說
到底要怎麼做出符合自己期待
但又可以表現得很有美感的作品？🥹
這個問題真的應該是每個創作者都一直在學習的課題吧！
在這篇文章中，我們將介紹工作與以前念書時期在開發流程上的差異，並深入瞭解CI/CD、Travis CI以及加解密的應用。 CI/CD是自動化的軟體開發實踐，而加解密則是保護機密資料安全的重要技術。
Pair programming，譯為「結對編程」，是敏捷軟體開發的一種方式，由兩位軟體工程師同時開發一個程式，簡單來說，原本一個人可以完成的工作，找了兩個人來做，人力成本直接變成兩倍！
｜本篇報導同步刊登於 科技島
在大量運用 AI 人工智慧的時代，為何外商軟體公司仍積極運用結對編程進行
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
今天來聊個最近很夯的主題 DDD，但不是 DDD 的本尊 Domain Driven Design，而是無所不在的 Database Driven Design，Database Driven Design 不是不好，只是你的模型容易變成貧血模型，邏輯都集中在 service 層等等。
有趣的是，Model 其實沒什麼嚴格的定義，所以每個人對 Model 的解讀也不盡相同，有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響)，有人覺得工作流程 (workflow) 是 Model 的一部份，我個人也有自己的想法，而且隨專案的規模和特性，也不是總是一樣的。
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
在創作的路上真的很多人問我說
到底要怎麼做出符合自己期待
但又可以表現得很有美感的作品？🥹
這個問題真的應該是每個創作者都一直在學習的課題吧！
在這篇文章中，我們將介紹工作與以前念書時期在開發流程上的差異，並深入瞭解CI/CD、Travis CI以及加解密的應用。 CI/CD是自動化的軟體開發實踐，而加解密則是保護機密資料安全的重要技術。
Pair programming，譯為「結對編程」，是敏捷軟體開發的一種方式，由兩位軟體工程師同時開發一個程式，簡單來說，原本一個人可以完成的工作，找了兩個人來做，人力成本直接變成兩倍！
｜本篇報導同步刊登於 科技島
在大量運用 AI 人工智慧的時代，為何外商軟體公司仍積極運用結對編程進行
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
今天來聊個最近很夯的主題 DDD，但不是 DDD 的本尊 Domain Driven Design，而是無所不在的 Database Driven Design，Database Driven Design 不是不好，只是你的模型容易變成貧血模型，邏輯都集中在 service 層等等。
有趣的是，Model 其實沒什麼嚴格的定義，所以每個人對 Model 的解讀也不盡相同，有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響)，有人覺得工作流程 (workflow) 是 Model 的一部份，我個人也有自己的想法，而且隨專案的規模和特性，也不是總是一樣的。
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。