歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
您现在的位置: Linux教程網 >> UnixLinux >  >> Linux編程 >> Linux編程

結對編程簡介

一個由聰明能干的開發者組成的敏捷團隊正在努力完成交付。他們遇到了一些意料之外的缺陷,正在努力修復生產環境中發現的缺陷;前端開發的工作量比後端開發更大,因此當前端開發者掙扎著試圖跟上進度時,後端開發者反而處於無所事事的狀態。可能他們需要更新控制器系統,但是 Brian 是唯一一個能夠看懂控制器代碼的人,不幸的是他現在正在忙其他事情。這個場景是不是很熟悉?結對編程可以有效地解決這些問題並給這個煎熬中的團隊帶來更多好處。那麼為什麼很多團隊不進行結對編程呢?

在《Pair Programming Illuminated》一書中,Laurie Williams 和 Robert Kessler 曾斷言:

我們發現很多人不願意采用結對編程——這需要改變現有習慣並且具備更強的溝通和協作能力……我們知道,如果被強迫采用結對編程,有些人寧可選擇辭職。[1]

讓團隊適應結對編程是一件很棘手的事情,那怎麼做才能讓你的團隊更容易接受結對編程呢?

問題到底出在哪裡?

首先我們來思考一下為什麼結對編程很難落實,以下是一些原因。

1. 對於團隊來說這是個很大的變化

很少有工作實踐能像結對編程這樣對團隊造成巨大影響。在傳統的工作中,開發者會“進入狀態”:帶上耳機打開音樂;手邊就是咖啡因飲料和零食。大部分開發者都不能適應在工作中和同事進行大量溝通,他們需要一段時間來適應對話狀態!

2. 精神高度集中

這是結對編程有效的秘籍之一:專注、專注、專注!如果你正在結對編程,那就不可能查看 Facebook、浏覽網頁或者回復收件箱中剛收到的郵件。

3. 疲憊

結對編程需要的專注和緊張程度高於大部分人的日常工作強度。結對編程會把你稍微推離舒適區並鍛煉你的專注能力。但是無論你多麼擅長結對編程,都會到達極限。Kent Beck 寫道“絕大多數程序員每天的結對時間不能超過五或者六個小時。”[2]

4. 大部分成員都沒有完全具備所需要的軟技能

人類不是生來就有同理心和超強的社交技能的。如果你在工作中和同事交流很少,那你在這方面的技能可能就會弱一些。想象一下,和一個缺乏社交技能的人緊密合作一整天是什麼感覺。或者,想象一下作為新手和一個不耐煩的老手一起編程的感覺。結對編程的兩方都需要很高的耐心和同理心。

5. 所有的改變都很困難

所有的變更管理專家都會告訴你——要求他人改變做事的方式會立刻激發恐懼反應,人們試圖理解改變對他們的影響。

既然如此艱難,為什麼我們還要改變呢?

接下來,我們會討論到底是什麼支撐你克服這些障礙。結對編程有很多好處,我們來看看你能獲得什麼回報。

  • 更高質量的代碼如果每行代碼在編寫的同時都在被審查,代碼質量就會急劇提高。由於審查者完全參與到代碼的編寫過程中,因此代碼審查的質量也會提升。類似 Alistair Cockburn 和 Laurie Williams 所做的研究,其他研究也對比了結對編程和單人編程產生的代碼,發現結對編程產生的代碼缺陷更少,設計更良好。在 Cockburn 和 Williams 的研究中,結對編程產生的程序“普遍比單人編程產生的程序短 20%,這表明前者的代碼更優雅、可維護性更高。”[3]
  • 更高的“巴士指數”“巴士指數”是一種表示團隊的知識、經驗和代碼擁有權共享程度的方法——如果有人離開(也就是被巴士撞了),我們中有多少人可以頂替他的位置?如果你的團隊巴士指數是1,那就意味著團隊中某人是不可或缺的——如果他突然離開,你的項目就有大麻煩了。結對編程可以讓你的巴士指數等於團隊成員數——每個人都可以在任何時間接手任何任務。
  • 更強的團隊凝聚力和同事整天在一起工作可以讓你更好地了解他們,從而更加理解他們,增強團隊凝聚力。
  • 更高的工作滿意度大多數程序員最後會發現和同事分擔編程任務可以讓自己更輕松——當他們習慣之後。他們不再需要自己承擔所有責任,並且可以互相幫助。
  • 更高的效率是的,沒錯,結對編程比單人編程的效率更高。這確實有點違反直覺,兩個人寫一份代碼怎麼會比兩個人分別寫兩份代碼更快呢?
    1. 當你和其他人一起討論的時候,可以更快地解決問題。隊友會幫助你把精力聚焦在問題上,並且能幫你搞定一些你自己不確定或者不熟悉的領域的問題。你花費在常見問題、研究和查找代碼語法上的時間會減少。
    2. 更少的缺陷意味著更多時間用在創建新特性而不是修復 bug 上!因此,效率更高。在上面提到的 Williams 和 Cockburn 的研究中,結對編程花費的人時只增加了大約 15%,遠小於從修復 bug 上節約的時間(bug 也減少了 15%)。因為在代碼編寫完成之後修復 bug 需要花費更多的時間,因此編寫同樣代碼,結對編程的總時間更少。
  • 更容易維護的代碼當兩個人一起編程時,他們需要在方法、數據結構甚至是變量和函數名上達成一致。這會減少其中一方隨意編寫代碼的可能性。結對編程者也更有可能選擇更加標准的語法、格式以及類似 TDD 這樣的最佳實踐。
  • 更有助於成員發展結對編程是軟件開發中學習新技能最快的方法之一。除了語言和技術,結對編程者還會共享很多其他技能,從解決問題的思路、算法到鍵盤快捷鍵和調試技巧。沒錯,你可以通過閱讀他人的代碼來學習他們解決問題的方法,但是和他們一起工作可以讓你更加清楚他們的思考過程。
  • 更高的團隊靈活性能讓人們快速地掌握技術和編程領域意味著他們可以以最小的代價從一個團隊轉移到另一個團隊。這種靈活性對所有人都有好處。如果一個項目突然需要外援,負責人可以從其他團隊“借”資源並讓資源快速發揮作用。類似地,如果開發者想學習一些新東西,或者想改變工作節奏,可以申請轉移到其他團隊。團隊可以以最小的損失來滿足這些申請。
  • 更少的會議如果團隊成員整天都在和其他人溝通,信息就可以快速流動,因此很少需要用會議來討論事情。這對於大部分開發者來說都極具吸引力,比起坐在會議室討論,他們更喜歡實際操作!

讀到這裡,希望你已經充分意識到結對編程的價值。當你和其他人討論結對編程的時候,可以直接引用這個列表中的內容。一定要把這個列表擺在最顯眼的位置,遇到困難的時候就提醒自己回報是什麼。

所以,如何進行結對編程?

下面我會介紹一些減輕痛苦的方法,能夠幫助你更好地推行結對編程。當你向開發者們推行新工具或者新技術的時候,要根據實際情況選擇合適的方法,結對編程也一樣。首先我們來看看 Gina Green 和 Alan Hevner 的研究。

Green 和 Hevner[4]研究了為什麼優秀的編程工具和技術經常會被程序員拒絕。調查了企業軟件的開發者之後,他們總結出三條推行新技術或者新工具的准則:

  1. 讓他們自己選擇何時使用開發者希望能夠自由決定結對編程的時間。千萬*不要*命令或者強制他們結對編程。如果你這樣做,他們會很不高興、不爽、不理睬你,甚至會反抗你。結對編程是優秀軟件開發者的思想結晶,並不是源於項目負責人或者流程控制專家。成千上萬的程序員在看到結對編程的好處之後會自願地接受它,這是唯一一種真正可行的結對編程推行方式。
  2. 指導他們正確地進行結對編程建立清晰明確的結對編程標准。結對編程並不是兩個人坐在一起,一個人編寫代碼並偶爾問另一個人問題。結對編程的意思是兩個人要非常專注於同一段代碼或者同一段思想,同時只有一個人打字。你需要向團隊成員介紹如何正確進行結對編程,比如:
    1. 讓稍差一些的隊友“主導”編程,即使他們需要很多指導。
    2. 共享控制權——兩個人都能控制鍵盤和程序設計。
    3. 意見出現分歧的時候要有禮貌地討論。
  3. 鼓勵他們(尤其是作為他們的領導!)無論你想做什麼改變,都需要清楚地表達出來,並且要不斷重復。即使你感覺自己像台壞掉的錄音機,也必須不斷重復直到完成改變。因此,要明確地表達出你想讓大家進行結對編程(同時不要把它變成命令)。如果你是領導那就更有效了,只要不斷重復,開發者一定會聽進去。

記住這三條准則之後,我們來看一些推行結對編程的方法。

方法一)細胞分裂

這種方法適用於你已經擁有,或者可以招聘到經驗豐富並且非常熱情的結對編程程序員。我們叫他們結對專家。你至少需要2~3 人來推行結對編程。具體方法如下:

  1. 組建一個隊伍,一半是結對專家,一半是結對新手(團隊中沒有結對編程經驗並且願意參與的人)
  2. 最初,所有的代碼必須由一個結對專家和一個結對新手結對完成。需要頻繁更換結對目標。
  3. 當新手開始適應的時候,你可以放寬專家-新手結對這個要求,但是至少要保證團隊穩定發展三個月,或者直到結對新手都“轉換”為結對專家。這個過程至少需要三個月,一定要有耐心。如果你很快就停止,那新手的經驗無法牢固掌握。
  4. 現在你有兩倍的結對專家了。如果你還有許多需要轉換的結對新手,可以把團隊一分為二並加入結對新手組成新團隊。確保在每個團隊中專家的數量都大於等於新手的數量,然後繼續執行步驟2。

這個過程開始很慢,但是會呈指數增長。從一個團隊開始,到第一年底你就會擁有八個團隊,到第十五個月就會擁有十六個團隊。到那時,你就很容易在團隊中推行其他技術實踐,比如測試驅動開發和持續集成。這些技能會快速傳播到整個團隊,因為大家都會對彼此負責。

注意:頻繁更換結對目標也被稱為“無序結對”。這樣���好處是知識可以在整個團隊中傳播。此外,這樣做也可以避免讓兩個人之間建立太深的感情,從而難以和其他人結對。Kent Beck 喜歡每隔幾個小時換一次結對對象,但是一天一次就足夠了。門羅創新公司會每周更換一次結對對象。

方法二)從零開始

如果你沒有任何經驗豐富的結對編程程序員,那就只能從零開始了。但是你還是可以遵循一個具體的方法。下面是 Laurie Williams 等人在《Pair Programming Illuminated》中推薦的方法。[5]

第一步是從團隊中找出一個聲望高並且願意協助你進行改變的開發者。選擇一些候選人並向他們解釋你想做什麼以及為什麼要這麼做。記住你的好處列表(上文提到過)。如果他們不能做出決定,可以讓他們參考一下列表中的好處。如果他們拒絕幫助你,那也要讓他們保持開放的心態,不要變成你的敵人,然後詢問下一個候選人。

當你找到認同你的開發者之後——我們叫他/她“結對支持者”——就可以進入下一步了。在這個階段,結對支持者開始逐漸向組織中的其他人介紹結對編程的思想。最好的方式是向其他程序員提供幫助,協助他們完成工作或者進行一對一幫助。這樣,結對支持者就可以不動聲色地和其他程序員建立起結對關系。如果這種關系進展順利,結對支持者就可以和隊友討論結對編程及其好處,並評估隊友對於結對編程的態度。這一階段的目標是發現組織內和你想法相同的人。

當你有一批可以接受結對編程的人之後,下一步就是和所有人進行公開的討論。列出一個暫時的自願性質的結對編程計劃——包括最初有多少對開發者和嘗試多長時間。因為需要一段時間來適應,所以最好嘗試三個月或者更久。讓大家公開討論他們對於結對編程的疑慮,並探討如何解決他們的問題。和他們討論評價標准,什麼樣的結果會讓大家相信結對編程是一件值得長期堅持的事情?討論如何收集數據從而可以驗證結果是否符合標准。最後詢問有多少人願意參與。如果可能的話可以加入物質獎勵,從而讓結對編程者在一個理想的新項目上開始工作。

其他建議

除了推行結對編程,還有一些需要思考的內容:

  • 並不是所有人都適合結對編程事實是組織中有些人可能永遠不會加入。你可以選擇:
  • 如果他們願意的話指導他們。一個優秀的教練可以幫助團隊中的成員處理恐懼和困難,幫助他們找到解決方法。
  • 給他們一些不需要結對編程的任務。或許你可以給他們分配一些單人編程也可以完成的任務。
  • 接受損失做好心裡准備,有些人會選擇離開。願意接受結對的新人可以代替他。
  • 把結對編程加入招聘流程在第一次面試候選人的時候和他進行一個簡單的結對編程練習是一個好辦法。讓專家觀察候選人,判斷他們是否具備和隊友溝通的能力。通過測試的候選人還需要和多個隊友進行一整天的結對編程,然後再決定是否聘用。
  • 確保有足夠的獎賞如果你獎賞單人行為和單人成就,那其實會影響結對編程模型,並鼓勵人們繼續單人工作。因此,必須重構你的獎勵體系,關注團隊而不是個人。
  • 你可能需要重新排列辦公桌結對編程需要一個長條辦公桌,讓他們挨著坐並且有足夠的活動空間。每個結對辦公桌需要放置兩個大顯示器、兩個鍵盤、兩個鼠標和一台電腦。盡量避免築牆,每個人都需要說話,他們不需要安靜。合作的嗡嗡聲將會給你的團隊帶來活力。
  • 提供娛樂設施並允許休息很多人都發現,在結對間隙放松幾分鐘非常有幫助。乒乓球桌是個不錯的選擇,可以實現短暫的激烈運動,並且非常有趣。
  • 牢記變化管理曲線無論要做出什麼改變,都需要准備好面對暫時的性能下降。如果大家都知道你已做好心理准備,那曲線就會緩和一些。
  • 調整組織的整體期望當你慶祝結對編程帶來的好處時,別忘了讓組織中其他人學會尊重結對編程並且不要期望電子郵件能夠得到立刻回復。可以使用其他方法來實現外界和你的團隊之間的信息流通,比如使用站立會議時間,或者指派一個團隊領導/敏捷教練來收取外界的請求並在適當的時間傳達給團隊成員。

分布式團隊

工作地點不一致的團隊怎麼辦呢?他們能獲得結對編程的好處嗎?當然可以,只要他們願意付出一些額外的努力。有許多工具可以幫助程序員共享屏幕和音/視頻,從而創建一個虛擬的結對環境。可能需要一些嘗試來判斷哪些工具最適合你的技術棧。雖然視頻是可選的,但是我很推薦視頻——獲得肢體語言和表情反饋可以極大地幫助你理解隊友的狀態。比如說,他保持沉默的原因是因為感到疑惑嗎?他在思考嗎?還是他起身去休息了呢?經驗豐富的遠程結對編程者 Joe Moore 的博客是學習遠程結對的好地方。讓團隊短期共同工作也是一個好辦法——比如一次或者兩次沖刺——這可以讓他們在遠程結對之前適應結對編程。

結論

結對編程對於所有軟件開發公司來說都極具價值。它可以顯著提高質量和速度,甚至可以提高開發者的工作滿意度。為了獲得這些價值,需要非常謹慎小心地把結對編程引入到你的團隊中。避免命令和強制要求,要不斷鼓勵和獎勵他們。這項強大的技能會在日復一日的練習中逐漸顯現出威力,讓你的團隊慢慢發現它的作用並達成共識。最後,別忘了,結對編程不適合所有人,所以要想好如何回應那些拒絕結對編程的團隊成員。

作者介紹

  Melinda Stelzer Jacobson是一名敏捷教練,堅信生產力和成功源自快樂的成員和重視信任、尊重和溝通的團隊。她的信念源自 15 年的軟件開發經驗,包括電信、銀行、科學設備、網站和互聯網程序。Melinda 住在舊金山,曾獲得敏捷專家認證、敏捷開發者認證、ICAgile 專業敏捷教練認證、DAD 黃帶和創新游戲合作架構師認證。在業余時間她會收養可愛的流浪兔,這樣它們就不會被安樂死。

Copyright © Linux教程網 All Rights Reserved