阿Han
阿Han

文字是留下記錄的一種媒介,將知識吸收轉化後輸出成文字進行保存。 ☕️ https://liker.land/willhanchen/civic

談談軟體開發 - Pair Programming

一起來了解軟體領域的開發流程,讓我們對軟體行業有基本認識吧!

會談這個主題主要是工作上預計進行Pair Programming的模型來開發,因而蒐集了一些關於Pair Programming這方面的相關概念與執行方向,並整理讓大家共同參考、討論。

但實務上真的可行嗎? 老闆同意嗎? 在執行前個人心中的兩大疑問,那麼以底下例子來看,這個問題的確沒有絕對的答案,取決於我們的思考面向。

如果大家認同航船過程中要有船長及副船長才足夠安全,那麼Pair Programming就是這樣的保險概念,透過雙人合作、互補來保障乘客順利抵達目的地,套用到產品的開發上也是如此,雖然兩個人共同做一件事情看似很蠢,但後續的經濟效益通常是我們沒有考慮的部分,試想我們的產品如果品質不好,在客戶端老是出包,那麼相信維護人員只會疲於奔命,對公司無非是莫大的損傷,產品給客人的觀感也不佳,影響公司的名聲,只要這樣的聲量傳開來,相信競爭者看到也一定很開心吧! 我想這並非公司所樂見的,因此Pari Programming就成為了這問題的解方之一,除了改善品質之外,還能用來進行新人訓練,甚至新產品研發都是非常適合的模式。

總之,取決於我們看事情的角度,假若我們重視的是後續的維護成本及產品品質,那麼Pair Programming就非常適合導入,但若僅是為了短期專案,只要快速結案就好,那麼用Pair Programming就多此一舉了,接著就直接進入主題吧!

Pair Programming是軟體領域中經典的開發方法,源自於極限編程的一種方法,又稱為結對編程,白話來說就是兩個人一起寫Code或者是完成某項指標任務,共同合作、互補、創新,主要會由以下兩個角色組成,分別是導航者(Navigator)跟駕駛者(Driver),導航者負責觀察、規劃及回饋,而駕駛者負責實際執行。

Pair Programming

過程中2位工程師會用同一台電腦,針對同一支程式進行開發,上圖中每個人都可能是導航者與駕駛者,因為可以互相交換角色,以不同觀點來發掘問題與提出解決方法,減少單獨開發的盲點,提升產品品質。

🔔還沒成為Potato會員的朋友點這裡加入哦,增加知識還能挖礦打造被動收入 🔔

優點

俗話說獨樹不成林,單打獨鬥難以成事,一個人寫程式想必存在許多盲點,而這個盲點如果有另一個人一起檢視,那麼或許問題就更容易被發現,也減少在正式環境上發生BUG的機會,但如果讓兩個工程師做一樣的事情卻沒有任何優點與回報的話,任何老闆都不會買單的,因此我們需要探討,Pair Programming究竟能帶給我們哪些優點呢? 以下整理幾個重點:

提升程式碼品質

協作的過程相當於多了一個人幫我們檢視程式碼,發現問題立刻就能夠修復,一但BUG數量減少,意味著QA的測試成本及後續維護成本也隨之減少,因此有效的Pair Programming能夠讓程式碼品質變的更好。

知識的學習和共享

雙方的認知上有所不同,因此過程中可以互相提出疑問和看法,並在即時的討論過程中激盪出新的解決方案,共同互補。

舉例來說,解決問題的演算法可能有多種,那麼假設今天獨自開發時,可能直覺的以過往經驗寫出一套自認完整的演算法,但透過第三者的檢視之後,或許對於原本的演算法能夠有新的想法,透過彼此討論後,又能產生一套效能改進後的演算法,但若沒有這種激盪的過程,或許自己就陷入了迷思之中,也難以產生創新的解決方案。

雙方在交換資訊的同時,也達到了知識共享的成果,透過這樣持續的合作,讓學習事半功倍,除此之外還會訓練彼此的溝通能力,因為我們需要跟搭檔相互溝通,以對方能理解的語言解釋,進而提升軟實力。

提升團隊效率

團隊中通常每個人都會負責一塊產品獨立的模組,假設某個功能模組的成員請假、離職時,若平常沒人熟悉該模組時,就沒有人可以接手了,那麼若專案時程又是非常急迫時,勢必對於團隊造成非常大的衝擊,效率也隨之延宕。

透過Pair Programming讓某項功能模組都至少有兩個人熟悉,專案忙碌時至少有人可以互相Cover,對於團隊以及公司都是百利無一害。

缺點

專案工時增加

兩個人共同開發相同的部分,那麼工時計算就會增加為2倍,這在老闆眼中顯然不是非常樂觀的開發方式,但增加的工時,若Pair Programming能夠有效的發揮成效,則增加的工時會在「減少的BUG」、「工作互補性」這兩塊拿回來。

消耗專注力

由於經常討論,因此容易導致開發到一半的過程中被打斷,造成專注力下降,因此一周選定幾天進行即可,不需要每天執行,否則反而帶來反效果。

如何執行?


選定目標與任務

  • 將大任務切成小任務。
  • 設定到期日,於期間內短期衝刺。

成員挑選

  • 一個資深一個資淺,切忌兩個不懂的新人共同進行,導致無效率行為。
  • 兩個理念不合,經常吵架的成員最好不要共同進行,避免耗費時間與精神在處理情緒上。

定期交換角色

  • 活化思緒,避免僵化。
  • 換位思考,以不同角色觀察不同面向。
  • 激盪想法,創造解決方法。
  • 減少盲點。

注意事項

  • 團隊不一定要採取指派的方式進行,而是有需求就可以進行結對,發揮敏捷開發的精神。
  • 當夥伴與自己已經趨近熟悉、未能再有更多突破時,就可以考慮先停止,或者重新結對。
  • 過程中應理性討論,而非互相仇視、指責、批評。

🔔還沒成為Potato會員的朋友點這裡加入哦,增加知識還能挖礦打造被動收入 🔔

書籍推薦

如果您正在為了專案效率而努力,或者想要了解更多關於敏捷開發的相關知識,非常推薦「SCRUM敏捷實戰手冊」,讓我們一起變強,學習更多不同領域的知識吧!

CC BY-NC-ND 2.0 版权声明

喜欢我的文章吗?
别忘了给点支持与赞赏,让我知道创作的路上有你陪伴。

加载中…
加载中…

发布评论