作者講述了這樣一種現實情況——一家公司需要實施某個非常重要的模組，但是此時它的高階開發人員Mr Senior很忙。因此，他們將模組給了新手Mr Newbie——他花了4個月來寫模組，兩個星期的時間來修復QA發現的大量bug，浪費了技術支援無數個小時用於揪出QA沒有發現的bug，甚至導致客戶以軟體滿是bug為由取消了合同，等等。最終，高階程式設計師站出來，用了一個月的時間從頭重寫，然後在經過QA快速的檢查之後，一個幾乎沒有bug的版面世了，所有人都很滿意。
結局很圓滿，沒錯，但是不知道你看出來沒有，其實所有的問題本來都是可以避免的，只要這家公司能夠在日常研發中引入程式碼審查程式。
現在，在我解釋如何避免這些問題之前，我想先描述一下我認為一個好的程式碼審查程式應該是什麼樣的。所有它需要做的就是遵循以下兩個簡單的原則：
- 沒有經過審查的程式碼不入主分支。哪怕是一行提交，哪怕是最高階開發人員寫的程式碼，都不能例外。
- 每個人都可以審查程式碼。即使是最初級的程式設計師，也可以參與進來。
第一個問題其實是不應該問的，因為即使是最資深最高階的開發人員也會時不時地犯錯。雖然手工的程式碼審查永遠不可能像自動化測試和指令碼化的手動QA那樣嚴謹，但是程式碼審查執行所需的時間更短，並且很容易發現自動化測試理解不了的問題——通常是位於架構層面的問題——這要是拖到以後修復就會變得很難很難。
至於第二個你不信任新手程式設計師的問題——答案很簡單。多一雙眼睛來檢查程式碼總是令人喜聞樂見的，但這也不是主要原因。我們真正想要實現的目的是提高初級程式設計師的技能。在審查時，他可以知道這些高階開發人員是如何編寫程式碼的。最重要的是，這將有助於他理解如何批判性地閱讀別人的程式碼，一兩個月後，他甚至能夠審查自己的程式碼，從而提高了他最終提交到儲存庫中的程式碼質量。
現在讓我們回過頭去再看前面作者提到的案例，我們可以發現，如果Mr Newbie寫的程式碼能夠拿給Mr Senior去審查，那麼他很多初始的錯誤在他第一次提交時就會被發現，甚至他還可以向Mr Senior請教和討論模組，從而創造出一個更好的架構，也許都不用像原來那樣花上4個月的時間就可以完成任務。此外，Mr Newbie由於知道需要經過高階開發人員的眼睛，因而在寫程式碼時會嚴格要求自己，用批判的眼光看自己的程式碼。而最重要的好處是，整個過程會教會Mr Newbie很多關於Mr Senior思考的方法，也許等到構建下一個模組時，他已經成為了Mr Intermediate（中級開發人員）。
評論(1)