談談軟體開發 - Pair Programming
閱讀時間約 5 分鐘
會談這個主題主要是工作上預計進行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敏捷實戰手冊」，讓我們一起變強，學習更多不同領域的知識吧！
為什麼會看到廣告
94會員
268內容數
哈囉，我是阿Han，是一位 👩💻 軟體研發工程師，喜歡閱讀、學習、撰寫文章及教學，擅長以圖代文，化繁為簡，除了幫助自己釐清思路之外，也希望藉由圖解的方式幫助大家共同學習，甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
阿Han的沙龍 的其他內容
你可能也想看
閒談軟體設計：技術債是選擇來的這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
2024-03-23
閒談軟體設計：Database Driven Design?今天來聊個最近很夯的主題 DDD，但不是 DDD 的本尊 Domain Driven Design，而是無所不在的 Database Driven Design，Database Driven Design 不是不好，只是你的模型容易變成貧血模型，邏輯都集中在 service 層等等。
2024-03-09
閒談軟體設計：Model Model Model有趣的是，Model 其實沒什麼嚴格的定義，所以每個人對 Model 的解讀也不盡相同，有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響)，有人覺得工作流程 (workflow) 是 Model 的一部份，我個人也有自己的想法，而且隨專案的規模和特性，也不是總是一樣的。
2024-03-02
閒談軟體設計：再來一碗起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
2024-02-24
閒談軟體設計：Cache, Repository style我自己偏好用 Repository 搭配 decorator 來管理 cache，而不是在 controller 層或是到處都有快取的邏輯，如果程式都是透過 Repository 更新資料，Repository 就會是一個不錯的地方更新快取，邏輯也就不會散亂在各處了。
2024-02-03
DayinUP【人才專訪】軟體開發｜Jason：Do or do not. There is no try.服務項目：網站開發／App開發／系統開發
2021-12-03
Obsidian筆記軟體簡介Obsidian是什麼
Obisidian是個強大的雙向連結筆記軟體，可以作為知識庫的連結，也可以當作個人筆記生活記錄使用。除了支援Markdown語法之外，還可以
2021-07-31
交友軟體測試後心得(meet the one)大概半年前看到海苔熊（目前觀察下來，書都很具體，值得翻）參與規劃的app，很好奇當人的情感用數據計算會有何結果。運作方式不贅述，介面操作很嚴謹乾淨，不會讓人有亂搞的感受。
其中一個讓我感興趣的功能: 媒合報告高，且有興趣的對象，你只有24h決定要不要約出來吃飯，不然，他就會徹底消失。我比較好奇的是，
2021-07-27
同步教學軟體：YouTube相信許多老師因為這波疫情的影響，需要拍攝線上教學課程的影片，所以這次要來介紹如何運用CyberLink的直播軟體Screen Recorder做YouTube直播！
2021-04-15
同步教學軟體：Cisco Webex Meetings除了 Zoom 之外，老師們也可以選擇用 Cisco Webex Meetings。Cisco Webex Meetings 擁有的功能和 Zoom 非常相似，同時它還多了記筆記的功能，讓學生完全無紙化的進行線上學習！
2021-03-31