程式碼檢視每個讀次文章的人都會知道是什麼意思。我們專案也是堅持在做程式碼檢視。今天我們仔細深入看看程式碼檢視的內涵及作用。

這幾年，我用過不同的程式碼檢視工具，並且我相信有一套程式碼檢視方法是最好的，下面是我所學到的。

有三種程式碼檢視的方法：

• 無程式碼檢視

每個開發者自由的check in程式碼，且每個人都可以檢查check in程式碼的功能清單，只要他願意，沒有責任與義務的區分。

• 非阻塞式程式碼檢視

當代碼check in後，檢視者根據修改清單，在某個時間點到程式碼庫上去檢視修改的程式碼。這種檢視方式不能阻止壞的程式碼被check in到程式碼庫上區。

• 阻塞式程式碼檢視

這種檢視方式式程式碼提交者通知檢視者檢視程式碼，程式碼在沒有得到檢視者同意之前不能提交到程式碼庫。

讓我們先來看第一種無程式碼檢視，我堅持認為沒有程式碼檢視的軟體開發，最終將會是一堆爛程式碼，不管程式設計師有多牛多有經驗。即使你是很牛的程式設計師，你不可能在所有時間都輸出高質量程式碼。月有圓缺，潮汐有漲落，程式設計師交付的程式碼質量也符合這個規律的。

當使用阻塞式檢視方法的時候，程式碼提交者不能提交程式碼，除非監視者認為程式碼質量已經符合要求。

當使用非阻塞式檢視方法的時候，程式碼會被立即提交到程式碼庫，但是檢視者可以在受到通知後檢視程式碼，我建議做一個提醒系統，不斷提醒那些懶惰的檢視者要完成程式碼檢視。

按照我的經驗來看，非阻塞式的程式碼檢視是可行的，在討論這個之前，我們先討論一下程式碼檢視到底能做什麼。因為我發現很多次人們從感覺上認識到的程式碼檢視的作用，與實際的不一致。
這裡有幾點事實：

• 程式碼檢視不能發現你程式碼中的嚴重bug

聽到這個你會很沮喪，但這是現實。當你的專案越來越複雜的時候，你做了一個更改，你不能從檢視者那裡得到一個意見，說：如果servlet接受20個請求，死鎖將會發生在A.java的723行和B.java的1410行”。取而代之的是，你會覺得程式碼檢視者的意見像是花瓶，可有可無。

• 程式碼檢視者能夠督促你認真寫程式碼

你知道你的程式碼將會被很多雙眼睛盯著，所以你會花額外多的時間讓程式碼可讀性更好。

我發現贊成阻塞式檢視方法的人，通常會覺得太多自由是導致程式碼質量差的原因。有一種觀點是：如果檢視者不帶著一種強烈的責任感去檢視程式碼，那麼檢視者就會鬆懈然後檢視就完成不了。
首先，我的經驗告訴我，這個觀點是不正確的。我發現在使用非阻塞方法的專案中，檢視者也非常努力的檢視，通常在少於一週的時間完成檢視任務。
不過，不管觀點的支援方還是反對方，都存在一個固有的缺陷：我們沒有認識到阻塞式檢視和非阻塞式檢視都式依賴你的團隊（或者專案的檢視規則）。

在阻塞式檢視場景下，當你要提交程式碼時候，你依賴於檢視者，他要意識到你一直在等著他來檢視程式碼，除此外沒有別的事情可做。如果不是有這個壓力在，監視者可能要幾天之後才能檢視你的程式碼，因為他可能別檢視任務淹沒了，可能他會認為程式碼提交者會找一些其他事情做，為了在等待檢視的時候不閒著。

我們可以彙總阻塞式檢視的問題：
我沒有實踐過阻塞式程式碼檢視，這些問題是從實施阻塞式程式碼檢視的團隊中反饋出來的。

• 等待檢視完成的過程中，開發者被阻塞了，什麼事情也幹不了。
• 開發者會一次儘可能提交多的程式碼，因為他們不想經常被阻塞，經常被中斷。
• 程式碼太多了會給檢視者帶來問題，他們要花更多的時間去讀懂程式碼，開發者被阻塞的時間也更長。因此就進入了惡性迴圈。

相比之下，非阻塞式的程式碼檢視方法會更好一些。
我認為非阻塞檢視方法能夠解決上面阻塞式檢視方法的所有問題。

• 監視者不會阻塞開發者的工作。
• 我會花多10秒來寫註釋，因為等會會有人會檢視。我發現從未被檢視過的程式碼很晦澀難懂，因為沒有一種督促讓他將程式碼寫的更易讀。

另外一種對程式碼檢視的實踐方法是結對程式設計，這個最近似乎很流行但是又似乎實踐不起來。

結對程式設計是阻塞式程式碼檢視方法和非阻塞式程式碼檢視方法的中間態，檢視者不會阻塞開發者，因為他們一起開發。
結對程式設計似乎是程式碼檢視的最佳實踐，但是結對程式設計也有缺點：
假如結對的兩個人能力差距很懸殊，則不如非阻塞式，因為能力強的這個人的生產率被能力弱的拉下來了。

對於結對程式設計看看專案組的具體情況來實施，針對一些核心業務邏輯的程式碼，可以找兩個能力相當且都對業務比較熟悉的開發者來實現，這種效果比較好，在開發程式碼的同時也做到了程式碼檢視的效果。

總結起來說，程式碼檢視是專案中必須要做一件事情，通常我們推薦非阻塞式程式碼檢視，對於核心業務，建議使用結對程式設計。