每當從各種公司聽到他們正在嘗試自動化部署/測試的事情，我都非常關注，但通常會很吃驚，他們很少會考慮去實行程式碼審查制度。
看到這種情況，我通常想問：如果程式碼沒有經過其它人的審查，你如何知道你要測試的是什麼？這答案(如果有的話)通常是捏著手指頭說有幾個人在做程式碼審查或“正在考慮中”。
沒有程式碼審查？真的嗎？不可思議？！？
程式碼審查不是可有可無的。
不論你採用什麼形式的測試過程，什麼形式的部署過程，沒有程式碼審查——gameover。為什麼？因為程式碼的質量是一種人能看懂的質量。不管你如何測試，有如何嚴謹的部署流程，只有當另外一個人看了這些程式碼，並且表明能看懂時，這些
程式碼才有意義。如果看不懂，你認為這樣的程式碼——雖然測試通過、部署符合流程——可以上線嗎？
沒有經過程式碼審查，測試說明不了任何問題。測試通過但沒有經過程式碼審查的程式碼仍然是有bug的。
什麼是程式碼審查？
請參考谷歌是如何做程式碼審查的。
設計中使用的“走廊UX測試”是說：在開始實現你的設計前，至少需要有一個人看過你的設計。程式碼審查是相同的道理。
程式碼審查是說：在把你的程式碼合併到程式碼庫裡之前，請至少找一個人看看你的程式碼。
如何進行程式碼審查？
下面是程式碼審查基本的步驟：
- 把身體向左轉。
- 看到另外一個程式設計師？拍拍他的肩膀。
- 讓他看你的顯示器。
- 說：這程式碼你能看懂嗎？我打算把它提交到程式碼庫裡。
- 聽他的建議。
- 自己做決定：是應該修改一下，還是繼續提交到程式碼庫裡。
就這樣。
現在，我想告訴你，有大量的程式碼審查工具可以使用。它們都能高度的自定義配置。它們的作用都是讓你程式碼審查過程更方面、靈活。
簡單的幾款程式碼審查工具
下面是我推薦的幾款簡單的程式碼審查工具(如果你的公司的程式設計師少於5千人)。
就是這些。雖然還有很多很多的程式碼審查工具，我很少聽說哪個程式設計師說喜歡它們的。而我的觀點，less, diff, github pull
requests能解決我們正常開發中的大部分程式碼審查問題。
如果你的程式碼審查過程過於複雜，需要使用大量的工具，這說明你過分的依賴於一些不必要的形式，你應該簡化它們。你可以說成你的反對的觀點，或在微博上和我們討論。
[英文原文：Do you do code review? ]