結對編程 VS 代碼審查：對比開發者文化
從上一份工作到現在的這份工作，我從結對編程的開發文化過渡到同行代碼審查，這個轉變過程是一個非常有趣的經歷。我認為我要記錄下些我所注意到的變化。
你可以找到很多標題是/（結對編程|代碼審查）的（利|弊）/這種樣式的文章，這些文章的作者都可以給出一套清晰且有說服力執行方案。我認為只要權衡它們的利弊，這兩種方案都是非常有效率的。我想就兩者的權衡策略提供些相對客觀的討論。
專有名詞的定義
因為“結對編程”和“代碼審查”這2個名詞都有很多種完全不同的解釋，所以首先讓我來定義下這篇文章中這2個名詞的含義。
當我提到結對編程文化，我指的是一個幾乎可以做到100%配對開發的團隊。其實就是2位開發人員在屏幕前合作完成一項任務。一位開發人員操作，另一位指導。兩位開發人員都參與到了代碼構建的過程中。每天的編程，開發工作就是與你的搭檔不斷交流。一旦小組（2位開發人員）完成任務，完成的代碼就直接提交給負責人且不需要進一步的審查。
當在會議室里大家緊盯投影儀上的代碼時，代碼審查文化可能會帶給團隊很多想法——至少對我來說是這樣的。當然這不是我對代碼審查的定義，這里我指的是借助自動化工具的同行代碼審查的過程。通過使用像Gerrit Patchsets 或是 GitHub Pull Requests這種運行機制, 開發人員自行編程并將完成的代碼提交給團隊的其他成員進行審查。逐行注釋是用來對代碼風格、代碼功能性進行質疑和評論的。一旦一項提交被審核通過，就會把它交給負責人。
成功的前提條件
兩種文化之間其實有些無可爭議的共同點：
穩固且持續的整合開發：基于每項任務的構建過程
牛X的核心開發人員：這些家伙可以幫助提高代碼庫的質量并完善體系結構。
代碼質量的重要性：團隊以及整個公司都知道保持一個高質量的代碼庫的價值。
不斷的自組織：整個團隊愿意定期評估并矯正調整他們的開發過程
結對編程的樂趣
接下來談一下結對編程。這真的是一次很棒的經歷，每個人都應該感受下。你可以找到其他贊美結對編程實踐效果的文章，但請讓我在這簡單的總結一下。
搭檔間似乎有一條高速交流通道，我們可以利用這點帶給團隊很多好處。你可以給菜鳥開發人員搭配個大神以此來培訓他。因為核心開發人員可以在團隊中快速傳播***的實踐經驗和技術知識。這樣，新的工具與技術自然而然就可以在團隊中得到分享，每個人都會進步。
兩個人結對編程可以共同分擔每天的工作的壓力和精力。有時這些狀態的起伏都是相互的。當一個人工作正勁而另一個分神時，狀態好的可以幫助另一個集中注意力。而當兩個人同時注意力高度集中時，那這工作效率是要逆天的節奏啊，他們互相可以依靠、信賴。
一個總是一起工作的小伙伴可以促進自我提高；每個人都想在他們尊重的人面前表現出色。而且這時我們往往更容易做出些策略決定，同時也會帶來更好的工作氣氛：兩個人都不會輕易的選擇捷徑，經常會就某個問題進行權衡討論。
代碼集體所有權這個概念更容易被接受，因為代碼都是至少兩人合作完成的。這些使得整個團隊能以更積極的心態面對失敗。
結對編程是團隊平衡的指向標
當一切都很順利的時候，結對編程看上去是那么的美好，但它同時也是只不羈的野獸需要去掌控。結對編程的效率可以充分反映團隊的平衡。結對編程對訓練菜鳥來說是非常好的一個方法，但是過分的稀釋核心人才，將他們分配給所有的初級開發人員會破壞團隊的生產力和氛圍。當一個團隊有過多的初級開發員，這種現象會發生的更快，結對編程就變成了場人才調配的俄羅斯方塊游戲。
同樣的平衡問題也會影響到知識庫。結對編程對于改進、重構之前的知識庫非常有效。一但一個新的庫或者分支被建立起來，就會增加結對人員分配和輪換的難度。
團隊需要不停的發現類似問題并盡早加以改正。知識和人才的失衡會導致團隊效率降低，更有可能破壞項目進程。
結對編程文化會滋生單一文化
結對編程是個較為高強度的實踐方法，它并不適合每個開發人員。這就意味著一個團隊要想采用結對編程，就必須招募那些在項目中熱愛與人交流的開發人員。團隊必須權衡其中的利弊，這樣才能達到結對編程的效果。
招募隊員的評價標準也層出不窮。每個開發人員都應該問問自己，“我是否愿意每天坐在別人旁邊和他一起編程、工作？”。這些問題對建設一個和諧團隊是非常重要的，但同時這些問題也會引起隊員間淺意識的恐懼與偏見。千萬別雇傭和團隊成員性格、背景截然不同的開發人員，他很有可能會破壞團隊氣氛。
結對編程會幫助團隊根據自身的利益構建統一的開發環境（包括開發工具、實踐方法、開發技術），但它也會讓團隊在開發的道路上一意孤行。促進技術產業的多樣性一直是項艱巨的任務，而結對編程文化更容易同化整個團隊。
結對編程不適于解決Hammock問題
結對編程有益于項目持續發展和某些技術知識的共享，但結對編程不利于做出謹慎的決定以及創造力的發揮。只有在處理更大的系統架構設計問題，我們才能做出這類謹慎的決定。
特別當大神與菜鳥配對時，大神會在編程前先做程序設計而不是把時間“浪費在”與菜鳥的交流上。這就會導致在程序設計中1+1<2。
有時候你需要代碼審查
當一個使用結對編程的團隊經歷了上述種種問題，核心開發人員便會開始懷疑搭檔們的業務能力。也許指不定在哪個配對小組中，兩個開發人員都是菜鳥。漸漸的團隊間的信任就會出現危機，這就意味著核心開發人員會覺得應該進行代碼審核。因此這種團隊間的信任危機會嚴重影響到結對編程的效果。
代碼審查的樂趣
起初，我覺得我會很不適應代碼審查文化，因為我已經習慣了結對編程文化。但事實卻相反，剛開始的體驗讓我覺得如魚得水。
在代碼審查中，沒人會看到你還未完全滿意的代碼。因為開發人員知道自己編寫的代碼最終都會被別人閱讀，所以保持好的編程風格的壓力激勵著開發人員。
與結對編程相比，代碼審查允許開發人員可以對問題進行深入思考。你可以花上一小時在房間內獨自思考、出去溜達尋找靈感、google下相關問題的背景信息、閱讀相關學術論文或者做些其他的事情。這種自由度可以讓開發人員找到更多解決問題的方法，有利于整個代碼構建的過程。
在一個使用代碼審查的團隊中，你寫的代碼就代表自己，因為你與同事們溝通的主要渠道就是你寫的代碼。這讓團隊能包容更多個性迥異的開發人員，在招募隊員時更有效率。你會很愿意與一位難以相處但代碼寫的非常好的開發人員共事。
代碼審查是異步的，這就帶來了很多好處。首先，團隊更容易為隊員們靈活地調整工作時間表。如果一個開放人員從早上5點到中午的工作狀態很好，那再好不過。如果另一個開發人員要去夜校學習，更傾向加班，這種情況也沒有問題。你也可以有策略的分配代碼審查任務，確保更多有經驗的開發者加入到代碼審查的過程中。這樣無形中提高了代碼的質量，避免項目中的漏洞。
我還發現使用代碼審查更能促使你對自己提的意見的價值進行思考。在結對編程的過程中，出于個人喜好或是強迫癥，你會忽略很多代碼細節。但在代碼審查的過程中，你必須判斷你推薦給別人修改代碼的意見是不是合理、可靠。我自己也有些堅持（放棄）建議的經歷。我希望未來我能在這部分記錄我更多的感受。
代碼審查讓你變得孤單
結對編程文化與代碼審查文化最明顯的差別就是每天你總是一個人構建代碼。對某些個性的人來說，這再好不過。但對我來說，這是個難以適應的轉變。
當然，有許多方式可以避免孤單帶給你的困擾。比如，和其他崗位的同事們呆在一起。我已經經歷了兩種截然不同的社交方式，想去了解 37 signals 的《remote work》這本書里面的論斷，也許它能給出如何處理不同社交方式的答案。
隱私 vs 自控
雖然你有在同事面前好好表現的動力，但你是唯一清楚每天你在干嘛的人。你可以出去溜達一圈尋找解決問題的***方法，但你也可以到處閑逛、與別人閑聊、不做正經事。
與結對編程相反，代碼審查對項目進度沒有嚴格規定。一個開發人員在固定的時間內沒有必須要完成任務的壓力。任務的進度完全于自己控制。這可能會造成嚴重的后果。
堆積起來的代碼審查任務
雖然由于代碼審查的異步性，它具有更靈活的項目進度安排時刻表，但在某些情況下它也會遇到執行的瓶頸，比如每個任務都需要審查，或是核心開發人員由于代碼審查的任務繁多而無法進行自己的編程開發。
在代碼審查中，開發人員間的交流慢且有局限性 —– 在別人編程時提出建議的速度遠遠比審核已經完成的代碼快。這種速度上的差距可以通過立刻審查已完成的代碼的方法有所減少。而且缺乏經驗的開發人員常常會落入一些代碼審查的陷阱中。
“嗯，好像適合我”
總之，結對編程促進開發人員在構建過程中交流，而代碼審查通常在任務構建完成后進行，這有利于項目的整合。代碼審查需要審閱者投入相當多的精力，這就會使審閱者對代碼質量的要求相對寬松。
哪個更好？
我希望我已經闡述了結對編程和代碼審查在保持代碼質量的實踐中的利與弊。***也是最重要的是團隊對所做的選擇要采取務實做法，因為這會讓團隊能坦誠的面對執行效果。一旦你意識到你使用方法的不足，你才能對此做出改進。
如果你還未解決上述的這些問題，那就加入一個注重代碼質量和項目進度的團隊，在團隊中試著去尋找這些問題的解決方案吧。
原文鏈接： Paul Hinze 翻譯： 伯樂在線 - shao
