結對程式設計與程式碼檢閱

Tom Dommett對“結對程式設計”（Pair Programming）有一些正面的經驗。他把它們寫下來，並分享給大家了：

這個概念是要讓兩個開發人員在同一台機器上工作。他們都有各自的鍵盤和滑鼠。在任何一個給定的時間，其中一個人作為“駕駛員”而另一個作為“領航員”。這兩個角色每隔一段時間（可以是一小時，也可能是任意時候）交換一次。“駕駛員”負責編寫代碼，“領航員”則負責閱讀、核對、拼字檢查以及在腦子裡測試代碼，同時思考當前碰到的問題以及接下來的任務。如果“駕駛員”遇到了問題，那麼有兩個人來一起尋找解決方案，而且通常情況下其中一個人總會想出來好點子。

其他的好處還包括，兩個人總是有不同的專長，而這些技能是可以傳遞的。當一個人向另一個人展示一些技巧、精妙的變通方案等等的時候，實際上他們是在進行臨時的培訓。

最終的結果是，兩個開發人員都完全瞭解代碼——代碼是如何工作的，以及為什麼它們是這樣設計的。很有可能這種工作方式下產生的代碼比一個開發人員單獨完成的要好，因為畢竟旁邊有個人在看著呢……代碼中包含錯誤或者勉強的拼湊以及那些將來可能造成維護問題的東西的可能性會小很多。

如果團隊大一點的話，結對的組合還可以每周變換一次，這樣每個團隊成員都有機會和不同的人結成夥伴。這會帶來巨大的好處，因為它可以讓開發人員們交談，並且用代碼這個通用語言來交換想法。

我們發現，結對程式設計的效率跟單獨工作一樣快。代碼被更快地完成，而且不需要返工。當代碼確實需要改動的時候，有不止一個人熟悉代碼。

這是一個令人鼓舞的結果。任何可以讓團隊更好交流的做法，我都會為之鼓掌。

結對程式設計這個想法使我很好奇，但我個人從來沒有經曆過這種工作方式。然而，我的確很享受和其他開發人員一起工作。每當我挨著一個開發夥伴坐下來跟他一起工作的時候，我總能從他們身上學到一些訣竅和技術。這樣參與的雙方都可以快速地學習。不過，我跟他們坐在一起的時間並不長。我對花上整整8小時這樣工作稍許有些擔心。我懷疑長時間這樣工作可能會使人疲勞，除非你在選擇你的編程夥伴上非常地幸運。

我曾經討論過“程式碼檢閱”（CodeReview）的功效。那是我親身經曆過的，因此我可以毫無保留地擔保程式碼檢閱的價值。我忍不住想知道，是否結對程式設計就是打過興奮劑的程式碼檢閱。它們之間不是一個替代另一個的關係——你當然可以兩個都做——但是，我懷疑結對程式設計的很多好處都可以通過可靠的同儕審查（PeerReview）來獲得。

不過，程式碼檢閱也不是萬能靈藥，就像MartyFried指出的那樣：

我對於代碼複查的經驗好壞參半。其中的一個問題是，似乎沒有人願意花時間去真正理解那些並不簡單的新代碼，所以反饋通常是非常籠統的。但是後來，當有人要在原有代碼基礎上添加功能或者修改錯誤的時候，他們通常會有很多的反饋（有時候他們還會怒氣沖沖地想要推倒重來），但那時候可能已經太晚了，而且效果也不會理想；之前寫那塊代碼的程式員可能也已經不在了。我覺得，程式碼檢閱或許多多少少有些好處，但要讓一個程式員告訴他的老闆他的程式員同伴工作很差勁就有點勉為其難了。

結對程式設計的優勢就在於它的即時性：當複查者就坐在你邊上的時候，忽略他是不可能的。大多數人在可以選擇的情況下都會選擇息事寧人。然而在結對程式設計中，這是不可能的。在代碼被寫下來的那一時刻，配對的每個人都必須立即理解代碼。結對或許有點唐突，但是它能強制一定程度的交流，這是你用其他方法可能永遠也做不到的。

另一方面，相比於把程式員的身體堆在同一個地方（這是結對程式設計的要求），同儕審查更有靈活性（其規模可大可小）。讓我們來看一看Macadamian在WINE項目中做程式碼檢閱的經曆吧：

譯者註：WINE（Wine Is Not an Emulator，即Wine不僅僅是一個模擬器）是一款優秀的Linux系統平台上的模擬器軟體，用來將Windows應用軟體運行到Linux平台上。該軟體更新頻繁，日臻完善，可以運行許多大型的Windows系統下的軟體。另外，英語單詞wine是葡萄酒的意思。

在WINE項目中，我們採用了兩個以前我們不曾用過的流程：公開的同儕審查——在這個流程中，新的代碼和補丁會通過一個郵件清單發送給所有參與這個項目的人；以及單一提交者——在這個流程中，項目主管對哪個補丁能被接受進入源碼樹有最終的決定權。

我們很快發現，Alexandre Julliard對於代碼能否進入源碼樹特別地挑剔——他自1994年開始就已經是WINE的維護者以及核心開發人員之一了。我們團隊的補丁都要經過他的仔細審查。當其中有些被駁回的時候，團隊裡就會有很多的抱怨：“My Code能正常工作。這個傢伙以為他是誰啊？期限就要到了，我們沒時間了!”但是，隨著項目的進展，我們意識到我們在開發有史以來最好的代碼。我們寫出了整潔、設計良好的代碼，並且能在第一遍就通過審核進入源碼樹很快就成為了一種驕傲。我們同時還發現，儘管這個項目十分龐大，並且開發人員散布在世界各地，我們仍然非常清楚地知道整個項目的進展狀況，因為我們在郵件清單上看到了每一個補丁。我們現在在每個項目上都採用程式碼檢閱；在更大型的項目上，我們還會建立一個內部郵件清單，並且指定一位單一提交者。或許在你的公司裡建立起程式碼檢閱的流程會很痛苦，而且團隊裡可能還會有些抱怨，但是在代碼的品質以及可維護性方面你將會看到巨大的進步。

我認為這兩種方法很明顯都是“純好事”，儘管它們都有各自的優點和不足。其中的一個就一定比另一個更有效嗎？我們應該兩個都做嗎？

歸根結底，我不認為這是一個二選一的問題，只要保證你有超過一雙的眼睛在看你所寫的代碼，不管你選擇用哪種方法都是可以的。當你的代碼有其他人幫你複查的時候——不管那個人就坐在你邊上，還是遠在幾千英裡以外——你就會開發出更好的軟體。這個我可以保證！。