程式碼審查的5點經驗教訓總結

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

“這個專案搞程式碼審查簡直是在浪費時間。”

“我沒時間做程式碼審查。”

“釋出會延遲，是因為我那個卑鄙的同事還沒有審查過我的程式碼。”

“你能相信我的同事居然要求我改我的程式碼嗎？我這麼優雅完美的程式碼哪裡還需要改呢。”

我們為什麼要做程式碼審查？

任何專業的軟體開發人員其最重要的目標之一就是要不斷提高自己的工作質量。但是隻有團隊協作才能力往一處使，勁往一處用，提高軟體質量。程式碼審查是實現這一目標最重要的途徑之一。特別是，程式碼審查可以：

• 從另一個角度發現缺陷和更好的解決辦法。
• 確保至少另外還有一人熟悉你的程式碼。
• 透過翻閱資深開發人員的程式碼，幫助培訓新員工。
• 促進知識共享。
• 激勵開發人員更好地寫程式碼、解決程式碼中的問題，以免在審查時被別人揪出來。

程式碼審查要徹底

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

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

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

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

• 囊括所有必要的測試。
• 已經寫入了恰當的設計文件。

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

避免過度的程式碼審查

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

• 沒有時間處理積壓的審查任務。
• 由於審查的沒有完成而導致了延遲釋出。
• 傻乎乎地再去審查已經不相干的程式碼，在交給你之後已經被改的面目全非。
• 因為時間緊迫急急忙忙地走個過場。

編寫可審查的程式碼

出現程式碼積壓而失控的問題，審查人員並不是唯一一個需要負責的人。舉個例子，如果你的同事花了一週時間為一個大型程式新增了亂七八糟的程式碼，那麼釋出的補丁就會變得很難審查，有太多的內容需要理解和鑽研。甚至於連程式碼目的和基本架構都看得雲裡霧裡。這是寫程式碼的不是。

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

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

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

建立可審查程式碼最重要的步驟之一就是給你的程式碼審查做註釋。這需要你自己預先審查過，然後在你認為有助於審查人員理解的地方新增註釋。我發現，註釋後的程式碼審查所需的時間相對較短（通常只需幾分鐘）。當然，程式碼註釋還是應該酌情使用。此外，有研究表明，開發人員自己在給程式碼註釋的時候也會發現許多存在的缺陷。

程式碼重構

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

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

如果增量重構程式碼還是不可行，那麼還有一個解決辦法就是結對程式設計。

解決爭端

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

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

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