我們時常會聽到團隊成員說：

“這個項目搞代碼審查簡直是在浪費時間。”

“我沒時間做代碼審查。”

“發(fā)布會延遲，是因為我那個卑鄙的同事還沒有審查過我的代碼。”

“你能相信我的同事居然要求我改我的代碼嗎？我這么優(yōu)雅***的代碼哪里還需要改呢。”

[[142649]]

我們?yōu)槭裁匆龃a審查？

任何專業(yè)的軟件開發(fā)人員其最重要的目標之一就是要不斷提高自己的工作質量。但是只有團隊協(xié)作才能力往一處使，勁往一處用，提高軟件質量。代碼審查是實現這一目標最重要的途徑之一。特別是，代碼審查可以：

• 從另一個角度發(fā)現缺陷和更好的解決辦法。

• 確保至少另外還有一人熟悉你的代碼。

• 通過翻閱資深開發(fā)人員的代碼，幫助培訓新員工。

• 促進知識共享。

• 激勵開發(fā)人員更好地寫代碼、解決代碼中的問題，以免在審查時被別人揪出來。

代碼審查要徹底

然而，除非能實實在在徹徹底底地在代碼審查上花時間和精力，否則上述目標是很難實現的。

我的看法是大概25％的原始開發(fā)時間應該花在代碼審查上。舉個例子，如果一個開發(fā)人員需要用兩天時間來實現某個程式，那么就應該花大約4小時進行審查。

當然時間并不是最重要的，關鍵是要看你能否正確審查代碼。你必須了解你正在審查的代碼。這意味著你不僅僅要知道它的的語法，還必須理解代碼是如何融 入應用程序這個大環(huán)境下，成為組件或庫的一部分。如果你不能把握每一行代碼的含義，那么你的審查就不到位，也不會非常有價值。這也是為什么良好執(zhí)行的代碼 審查，大多不可能迅速被完成：因為我們需要時間來研究各種代碼，如能觸發(fā)給定功能以確保第三方API正確使用的代碼。

[[142650]]

在審查時，除了要尋找代碼缺陷和其他問題，你還應該確保：

• 囊括所有必要的測試。

• 已經寫入了恰當的設計文檔。

即使是那些擅于寫測試和文檔的開發(fā)人員，也會在改變代碼的時候忘記更新。代碼評審時就應該確保這些資料不會隨著時間而變得毫無用處。

避免過度的代碼審查

開發(fā)人員應該努力清空積壓的審查任務。有一種方法是在早上代碼審查，在開始自己的開發(fā)工作之前先搞定審查任務。當然你也可以午飯前后或者是一天結束之時審查代碼。總而言之，你應該將代碼當作是日常工作的一部分，而不是工作的負累，所以你應該避免：

• 沒有時間處理積壓的審查任務。

• 由于審查的沒有完成而導致了延遲發(fā)布。

• 傻乎乎地再去審查已經不相干的代碼，在交給你之后已經被改的面目全非。

• 因為時間緊迫急急忙忙地走個過場。

編寫可審查的代碼

出現代碼積壓而失控的問題，審查人員并不是唯一一個需要負責的人。舉個例子，如果你的同事花了一周時間為一個大型程序添加了亂七八糟的代碼，那么發(fā)布的補丁就會變得很難審查，有太多的內容需要理解和鉆研。甚至于連代碼目的和基本架構都看得云里霧里。這是寫代碼的不是。

在編寫可審查的代碼之前，還需要做一些準備。如果需要做一些棘手的架構決策，那么***和審查人員先討論一番。這將能讓你的代碼更容易審閱和理解，因 為他們提前已經知道你想實現什么以及計劃如何實現。這也可以避免，要是審查人員之后提出一個截然不同又更好的方法，而導致你不得不重寫一大片代碼的情況。

項目架構應該在設計文檔中詳細描述。這很重要，因為它能讓新的項目人員更快地理解現有的代碼庫，還能有助于審查人員更好地完成他們的工作。此外，單元測試能讓審查人員更好地理解各個組件的使用。

如果在你的補丁中還包含了第三方代碼，那么單獨提交。試想一下，要是代碼中間插進去9000行jQuery，是不是大大增加了審查的難度！

創(chuàng)建可審查代碼最重要的步驟之一就是給你的代碼審查做注釋。這需要你自己預先審查過，然后在你認為有助于審查人員理解的地方添加注釋。我發(fā)現，注釋 后的代碼審查所需的時間相對較短（通常只需幾分鐘）。當然，代碼注釋還是應該酌情使用。此外，有研究表明，開發(fā)人員自己在給代碼注釋的時候也會發(fā)現許多存 在的缺陷。

代碼重構

有時候，我們必須重構代碼庫。如果恰巧碰到的是一個大型的應用程序，那可能就會需要幾天的時間（甚至更多），同時會產生大量的補丁。在這種情況下，想要做到標準流程的代碼評審可能是不切實際的。

***的解決辦法是逐步重構代碼。先給定一個合理范圍，確定相應的代碼庫，然后朝著目標方向做整改和重構。***部分完成之后，審查并發(fā)布，然后進行第 二部分的重構……，直到全部完成。這種階段式的方法可能并不總是可行的，但是如果我們在思考和規(guī)劃時使用這樣的方法，可以避免重構時大規(guī)模的單片補丁。當 然這種方式可能需要的重構時間更多，但是也會產出更高質量的代碼，以及更加輕松的審查過程。

如果增量重構代碼還是不可行，那么還有一個解決辦法就是結對編程。

[[142651]]

解決爭端

毫無疑問，團隊中的每個成員都是人才，但是這也很容易導致在面對特定的編碼問題時，會出現意見分歧的情況。作為開發(fā)人員，我們應該保持開放的態(tài)度，并且也要能虛心接受審查人員給出的不同意見。

而作為審查人員，說話要委婉。在提建議之前，先考慮一下你的意見是否真的更好或者僅僅只是因為品味不同而已。如果你選擇的代碼區(qū)域確實需要改進的， 那么整個說服過程就會簡單得多。并且話要這樣講，“這里還值得考慮一下……”，“有人建議說……”，而不是“我閉著眼睛寫的算法也能比你的高效。”

當然如果你們雙方都不肯妥協(xié)的話，可以要求你們都尊重的開發(fā)人員來看一看，給出他的意見。