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