從上一份工作到現在的這份工作，我從結對程式設計的開發文化過渡到同行代碼審查，這個轉變過程是一個非常有趣的經曆。我認為我要記錄下些我所注意到的變化。
你可以找到很多标題是/（結對程式設計|代碼審查）的（利|弊）/這種樣式的文章，這些文章的作者都可以給出一套清晰且有說服力執行方案。我認為隻要權衡它們的利弊，這兩種方案都是非常有效率的。我想就兩者的權衡政策提供些相對客觀的讨論。
專有名詞的定義
因為“結對程式設計”和“代碼審查”這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