代碼審查的5點經驗教訓總結
英文原文：Practical Lessons in Peer Code Review
我們時常會聽到團隊成員說：
“這個項目搞代碼審查簡直是在浪費時間。”
“我沒時間做代碼審查。”
“發布會延遲，是因為我那個卑鄙的同事還沒有審查過我的代碼。”
“你能相信我的同事居然要求我改我的代碼嗎？我這么優雅完美的代碼哪里還需要改呢。”
我們為什么要做代碼審查？
任何專業的軟件開發人員其最重要的目標之一就是要不斷提高自己的工作質量。但是只有團隊協作才能力往一處使，勁往一處用，提高軟件質量。代碼審查是實現這一目標最重要的途徑之一。特別是，代碼審查可以：
- 從另一個角度發現缺陷和更好的解決辦法。
- 確保至少另外還有一人熟悉你的代碼。
- 通過翻閱資深開發人員的代碼，幫助培訓新員工。
- 促進知識共享。
- 激勵開發人員更好地寫代碼、解決代碼中的問題，以免在審查時被別人揪出來。
代碼審查要徹底
然而，除非能實實在在徹徹底底地在代碼審查上花時間和精力，否則上述目標是很難實現的。
我的看法是大概 25％ 的原始開發時間應該花在代碼審查上。舉個例子，如果一個開發人員需要用兩天時間來實現某個程式，那么就應該花大約 4 小時進行審查。
當然時間并不是最重要的，關鍵是要看你能否正確審查代碼。你必須了解你正在審查的代碼。這意味著你不僅僅要知道它的的語法，還必須理解代碼是如 何融入應用程序這個大環境下，成為組件或庫的一部分。如果你不能把握每一行代碼的含義，那么你的審查就不到位，也不會非常有價值。這也是為什么良好執行的 代碼審查，大多不可能迅速被完成：因為我們需要時間來研究各種代碼，如能觸發給定功能以確保第三方 API 正確使用的代碼。
在審查時，除了要尋找代碼缺陷和其他問題，你還應該確保：
- 囊括所有必要的測試。
- 已經寫入了恰當的設計文檔。
即使是那些擅于寫測試和文檔的開發人員，也會在改變代碼的時候忘記更新。代碼評審時就應該確保這些資料不會隨著時間而變得毫無用處。
避免過度的代碼審查
開發人員應該努力清空積壓的審查任務。有一種方法是在早上代碼審查，在開始自己的開發工作之前先搞定審查任務。當然你也可以午飯前后或者是一天結束之時審查代碼。總而言之，你應該將代碼當作是日常工作的一部分，而不是工作的負累，所以你應該避免：
- 沒有時間處理積壓的審查任務。
- 由于審查的沒有完成而導致了延遲發布。
- 傻乎乎地再去審查已經不相干的代碼，在交給你之后已經被改的面目全非。
- 因為時間緊迫急急忙忙地走個過場。
編寫可審查的代碼
出現代碼積壓而失控的問題，審查人員并不是唯一一個需要負責的人。舉個例子，如果你的同事花了一周時間為一個大型程序添加了亂七八糟的代碼，那么發布的補丁就會變得很難審查，有太多的內容需要理解和鉆研。甚至于連代碼目的和基本架構都看得云里霧里。這是寫代碼的不是。
在編寫可審查的代碼之前，還需要做一些準備。如果需要做一些棘手的架構決策，那么最好和審查人員先討論一番。這將能讓你的代碼更容易審閱和理 解，因為他們提前已經知道你想實現什么以及計劃如何實現。這也可以避免，要是審查人員之后提出一個截然不同又更好的方法，而導致你不得不重寫一大片代碼的 情況。
項目架構應該在設計文檔中詳細描述。這很重要，因為它能讓新的項目人員更快地理解現有的代碼庫，還能有助于審查人員更好地完成他們的工作。此外，單元測試能讓審查人員更好地理解各個組件的使用。
如果在你的補丁中還包含了第三方代碼，那么單獨提交。試想一下，要是代碼中間插進去 9000 行 jQuery，是不是大大增加了審查的難度！
創建可審查代碼最重要的步驟之一就是給你的代碼審查做注釋。這需要你自己預先審查過，然后在你認為有助于審查人員理解的地方添加注釋。我發現， 注釋后的代碼審查所需的時間相對較短（通常只需幾分鐘）。當然，代碼注釋還是應該酌情使用。此外，有研究表明，開發人員自己在給代碼注釋的時候也會發現許 多存在的缺陷。
代碼重構
有時候，我們必須重構代碼庫。如果恰巧碰到的是一個大型的應用程序，那可能就會需要幾天的時間（甚至更多），同時會產生大量的補丁。在這種情況下，想要做到標準流程的代碼評審可能是不切實際的。
最好的解決辦法是逐步重構代碼。先給定一個合理范圍，確定相應的代碼庫，然后朝著目標方向做整改和重構。第一部分完成之后，審查并發布，然后進 行第二部分的重構……，直到全部完成。這種階段式的方法可能并不總是可行的，但是如果我們在思考和規劃時使用這樣的方法，可以避免重構時大規模的單片補 丁。當然這種方式可能需要的重構時間更多，但是也會產出更高質量的代碼，以及更加輕松的審查過程。
如果增量重構代碼還是不可行，那么還有一個解決辦法就是結對編程。
解決爭端
毫無疑問，團隊中的每個成員都是人才，但是這也很容易導致在面對特定的編碼問題時，會出現意見分歧的情況。作為開發人員，我們應該保持開放的態度，并且也要能虛心接受審查人員給出的不同意見。
而作為審查人員，說話要委婉。在提建議之前，先考慮一下你的意見是否真的更好或者僅僅只是因為品味不同而已。如果你選擇的代碼區域確實需要改進 的，那么整個說服過程就會簡單得多。并且話要這樣講，“這里還值得考慮一下……”，“有人建議說……”，而不是“我閉著眼睛寫的算法也能比你的高效。”
當然如果你們雙方都不肯妥協的話，可以要求你們都尊重的開發人員來看一看，給出他的意見。
-
譯文鏈接：http://www.codeceo.com/article/code-review-5-tips.html
翻譯作者：碼農網 – 小峰