從上一份工作到現(xiàn)在的這份工作，我從結(jié)對編程的開發(fā)文化過渡到同行代碼審查，這個轉(zhuǎn)變過程是一個非常有趣的經(jīng)歷。我認為我要記錄下些我所注意到的變化。

你可以找到很多標題是/（結(jié)對編程|代碼審查）的（利|弊）/這種樣式的文章，這些文章的作者都可以給出一套清晰且有說服力執(zhí)行方案。我認為只要權(quán)衡它們的利弊，這兩種方案都是非常有效率的。我想就兩者的權(quán)衡策略提供些相對客觀的討論。 

專有名詞的定義

因為“結(jié)對編程”和“代碼審查”這2個名詞都有很多種完全不同的解釋，所以首先讓我來定義下這篇文章中這2個名詞的含義。

當我提到結(jié)對編程文化，我指的是一個幾乎可以做到100%配對開發(fā)的團隊。其實就是2位開發(fā)人員在屏幕前合作完 成一項任務(wù)。一位開發(fā)人員操作，另一位指導。兩位開發(fā)人員都參與到了代碼構(gòu)建的過程中。每天的編程，開發(fā)工作就是與你的搭檔不斷交流。一旦小組（2位開發(fā) 人員）完成任務(wù)，完成的代碼就直接提交給負責人且不需要進一步的審查。

當在會議室里大家緊盯投影儀上的代碼時，代碼審查文化可能會帶給團隊很多想法——至少對我來說是這樣的。當然這 不是我對代碼審查的定義，這里我指的是借助自動化工具的同行代碼審查的過程。通過使用像Gerrit Patchsets 或是 GitHub Pull Requests這種運行機制, 開發(fā)人員自行編程并將完成的代碼提交給團隊的其他成員進行審查。逐行注釋是用來對代碼風格、代碼功能性進行質(zhì)疑和評論的。一旦一項提交被審核通過，就會把 它交給負責人。

成功的前提條件

兩種文化之間其實有些無可爭議的共同點：

• 穩(wěn)固且持續(xù)的整合開發(fā)：基于每項任務(wù)的構(gòu)建過程

• 牛X的核心開發(fā)人員：這些家伙可以幫助提高代碼庫的質(zhì)量并完善體系結(jié)構(gòu)。

• 代碼質(zhì)量的重要性：團隊以及整個公司都知道保持一個高質(zhì)量的代碼庫的價值。

• 不斷的自組織：整個團隊愿意定期評估并矯正調(diào)整他們的開發(fā)過程 

結(jié)對編程的樂趣

接下來談一下結(jié)對編程。這真的是一次很棒的經(jīng)歷，每個人都應(yīng)該感受下。你可以找到其他贊美結(jié)對編程實踐效果的文章，但請讓我在這簡單的總結(jié)一下。

[[145908]]

搭檔間似乎有一條高速交流通道，我們可以利用這點帶給團隊很多好處。你可以給菜鳥開發(fā)人員搭配個大神以此來培訓他。因為核心開發(fā)人員可以在團隊中快速傳播***的實踐經(jīng)驗和技術(shù)知識。這樣，新的工具與技術(shù)自然而然就可以在團隊中得到分享，每個人都會進步。

兩個人結(jié)對編程可以共同分擔每天的工作的壓力和精力。有時這些狀態(tài)的起伏都是相互的。當一個人工作正勁而另一個分神時，狀態(tài)好的可以幫助另一個集中注意力。而當兩個人同時注意力高度集中時，那這工作效率是要逆天的節(jié)奏啊，他們互相可以依靠、信賴。

一個總是一起工作的小伙伴可以促進自我提高；每個人都想在他們尊重的人面前表現(xiàn)出色。而且這時我們往往更容易做出些策略決定，同時也會帶來更好的工作氣氛：兩個人都不會輕易的選擇捷徑，經(jīng)常會就某個問題進行權(quán)衡討論。

代碼集體所有權(quán)這個概念更容易被接受，因為代碼都是至少兩人合作完成的。這些使得整個團隊能以更積極的心態(tài)面對失敗。 

結(jié)對編程是團隊平衡的指向標

當一切都很順利的時候，結(jié)對編程看上去是那么的美好，但它同時也是只不羈的野獸需要去掌控。結(jié)對編程的效率可以充分反映團隊的平衡。結(jié)對編程對訓練 菜鳥來說是非常好的一個方法，但是過分的稀釋核心人才，將他們分配給所有的初級開發(fā)人員會破壞團隊的生產(chǎn)力和氛圍。當一個團隊有過多的初級開發(fā)員，這種現(xiàn) 象會發(fā)生的更快，結(jié)對編程就變成了場人才調(diào)配的俄羅斯方塊游戲。

同樣的平衡問題也會影響到知識庫。結(jié)對編程對于改進、重構(gòu)之前的知識庫非常有效。一但一個新的庫或者分支被建立起來，就會增加結(jié)對人員分配和輪換的難度。

團隊需要不停的發(fā)現(xiàn)類似問題并盡早加以改正。知識和人才的失衡會導致團隊效率降低，更有可能破壞項目進程。

結(jié)對編程文化會滋生單一文化

結(jié)對編程是個較為高強度的實踐方法，它并不適合每個開發(fā)人員。這就意味著一個團隊要想采用結(jié)對編程，就必須招募那些在項目中熱愛與人交流的開發(fā)人員。團隊必須權(quán)衡其中的利弊，這樣才能達到結(jié)對編程的效果。

招募隊員的評價標準也層出不窮。每個開發(fā)人員都應(yīng)該問問自己，“我是否愿意每天坐在別人旁邊和他一起編程、工作？”。這些問題對建設(shè)一個和諧團隊是 非常重要的，但同時這些問題也會引起隊員間淺意識的恐懼與偏見。千萬別雇傭和團隊成員性格、背景截然不同的開發(fā)人員，他很有可能會破壞團隊氣氛。

結(jié)對編程會幫助團隊根據(jù)自身的利益構(gòu)建統(tǒng)一的開發(fā)環(huán)境（包括開發(fā)工具、實踐方法、開發(fā)技術(shù)），但它也會讓團隊在開發(fā)的道路上一意孤行。促進技術(shù)產(chǎn)業(yè)的多樣性一直是項艱巨的任務(wù)，而結(jié)對編程文化更容易同化整個團隊。

結(jié)對編程不適于解決Hammock問題

結(jié)對編程有益于項目持續(xù)發(fā)展和某些技術(shù)知識的共享，但結(jié)對編程不利于做出謹慎的決定以及創(chuàng)造力的發(fā)揮。只有在處理更大的系統(tǒng)架構(gòu)設(shè)計問題，我們才能做出這類謹慎的決定。

特別當大神與菜鳥配對時，大神會在編程前先做程序設(shè)計而不是把時間“浪費在”與菜鳥的交流上。這就會導致在程序設(shè)計中1+1<2。

有時候你需要代碼審查

當一個使用結(jié)對編程的團隊經(jīng)歷了上述種種問題，核心開發(fā)人員便會開始懷疑搭檔們的業(yè)務(wù)能力。也許指不定在哪個配對小組中，兩個開發(fā)人員都是菜鳥。漸 漸的團隊間的信任就會出現(xiàn)危機，這就意味著核心開發(fā)人員會覺得應(yīng)該進行代碼審核。因此這種團隊間的信任危機會嚴重影響到結(jié)對編程的效果。 

[[145910]]

代碼審查的樂趣

起初，我覺得我會很不適應(yīng)代碼審查文化，因為我已經(jīng)習慣了結(jié)對編程文化。但事實卻相反，剛開始的體驗讓我覺得如魚得水。

在代碼審查中，沒人會看到你還未完全滿意的代碼。因為開發(fā)人員知道自己編寫的代碼最終都會被別人閱讀，所以保持好的編程風格的壓力激勵著開發(fā)人員。

與結(jié)對編程相比，代碼審查允許開發(fā)人員可以對問題進行深入思考。你可以花上一小時在房間內(nèi)獨自思考、出去溜達尋找靈感、google下相關(guān)問題的背景信息、閱讀相關(guān)學術(shù)論文或者做些其他的事情。這種自由度可以讓開發(fā)人員找到更多解決問題的方法，有利于整個代碼構(gòu)建的過程。

在一個使用代碼審查的團隊中，你寫的代碼就代表自己，因為你與同事們溝通的主要渠道就是你寫的代碼。這讓團隊能包容更多個性迥異的開發(fā)人員，在招募隊員時更有效率。你會很愿意與一位難以相處但代碼寫的非常好的開發(fā)人員共事。

代碼審查是異步的，這就帶來了很多好處。首先，團隊更容易為隊員們靈活地調(diào)整工作時間表。如果一個開放人員從早上5點到中午的工作狀態(tài)很好，那再好 不過。如果另一個開發(fā)人員要去夜校學習，更傾向加班，這種情況也沒有問題。你也可以有策略的分配代碼審查任務(wù)，確保更多有經(jīng)驗的開發(fā)者加入到代碼審查的過 程中。這樣無形中提高了代碼的質(zhì)量，避免項目中的漏洞。

我還發(fā)現(xiàn)使用代碼審查更能促使你對自己提的意見的價值進行思考。在結(jié)對編程的過程中，出于個人喜好或是強迫癥，你會忽略很多代碼細節(jié)。但在代碼審查 的過程中，你必須判斷你推薦給別人修改代碼的意見是不是合理、可靠。我自己也有些堅持（放棄）建議的經(jīng)歷。我希望未來我能在這部分記錄我更多的感受。

代碼審查讓你變得孤單

結(jié)對編程文化與代碼審查文化最明顯的差別就是每天你總是一個人構(gòu)建代碼。對某些個性的人來說，這再好不過。但對我來說，這是個難以適應(yīng)的轉(zhuǎn)變。

當然，有許多方式可以避免孤單帶給你的困擾。比如，和其他崗位的同事們呆在一起。我已經(jīng)經(jīng)歷了兩種截然不同的社交方式，想去了解 37 signals 的《remote work》這本書里面的論斷，也許它能給出如何處理不同社交方式的答案。

隱私 vs 自控

雖然你有在同事面前好好表現(xiàn)的動力，但你是唯一清楚每天你在干嘛的人。你可以出去溜達一圈尋找解決問題的***方法，但你也可以到處閑逛、與別人閑聊、不做正經(jīng)事。

與結(jié)對編程相反，代碼審查對項目進度沒有嚴格規(guī)定。一個開發(fā)人員在固定的時間內(nèi)沒有必須要完成任務(wù)的壓力。任務(wù)的進度完全于自己控制。這可能會造成嚴重的后果。

堆積起來的代碼審查任務(wù)

雖然由于代碼審查的異步性，它具有更靈活的項目進度安排時刻表，但在某些情況下它也會遇到執(zhí)行的瓶頸，比如每個任務(wù)都需要審查，或是核心開發(fā)人員由于代碼審查的任務(wù)繁多而無法進行自己的編程開發(fā)。

在代碼審查中，開發(fā)人員間的交流慢且有局限性 —– 在別人編程時提出建議的速度遠遠比審核已經(jīng)完成的代碼快。這種速度上的差距可以通過立刻審查已完成的代碼的方法有所減少。而且缺乏經(jīng)驗的開發(fā)人員常常會落入一些代碼審查的陷阱中。

“嗯，好像適合我”

總之，結(jié)對編程促進開發(fā)人員在構(gòu)建過程中交流，而代碼審查通常在任務(wù)構(gòu)建完成后進行，這有利于項目的整合。代碼審查需要審閱者投入相當多的精力，這就會使審閱者對代碼質(zhì)量的要求相對寬松。

哪個更好？

我希望我已經(jīng)闡述了結(jié)對編程和代碼審查在保持代碼質(zhì)量的實踐中的利與弊。***也是最重要的是團隊對所做的選擇要采取務(wù)實做法，因為這會讓團隊能坦誠的面對執(zhí)行效果。一旦你意識到你使用方法的不足，你才能對此做出改進。

如果你還未解決上述的這些問題，那就加入一個注重代碼質(zhì)量和項目進度的團隊，在團隊中試著去尋找這些問題的解決方案吧。

原文：http://phinze.github.io/2013/12/08/pairing-vs-code-review.html 作者： Paul Hinze
譯文：http://blog.jobbole.com/61349/ 譯者： shao