在我們公司裡要執行代碼審查。這是我們每天的例行工作。事實上，今天的我們正是從這種一直堅持探索的漫長道路上走出來的。我們嘗試各種技術、方法和工具，直到我們走到今天的成就(但這並不是說我們就此停步)。
在這旅途中，我們發現了很多的陷阱和危險，它們等待新手們上鉤。這篇文章就是關於它們的：代碼審查中的陷阱和誤解。
代碼控制：很 多公司都把代碼審查當成控制代碼的方法。很多這樣的公司都使用預提交策略。這種策略大多時候都是開源項目中使用，因為會有成百上千的提交者。可在一般的公 司裡，很少會有這種情況。如果你僱用一個人，這意味這你要完全信任他，允許他將代碼提交到代碼庫裡。我知道有些公司會忍不住制定一些規程，要求程式設計師在提 交代碼前必須進行「審查」和「批准」，但這並不能保證代碼的質量。而且，程式設計師很快就會把這種代碼審查當作一種「愚蠢」的公司形式過程，會開始抵制它(例 如，每月改一次密碼。例如，使用像mypass1,mypass2等的密碼)。
審判廳：
不 要把代碼審查當成尋找替罪羊和追究責任的工具。比如說，這有一個錯誤，你找到「審查」這段代碼的人，並責備他沒有發現這個問題。這種事情會給公司裡的開發 工作帶來嚴重的影響。人們會挑出每個分號放置不正確的地方，因為他們擔心會被當成替罪羊。團隊成員開始缺乏信心，並最終失去互信。
責任任務：不要過分要求程式設計師做代碼審查。如果你強迫他們每天做一小時的代碼審查，他們很快就會痛恨它，把它當成一種無趣的任務。代碼審查是一種學習，是表揚，是獲得反饋，是一種十分社交性的活動。代碼審查應該是有趣的，不要讓它變的無聊。
我和我的代碼如 果你的代碼被某人審查，他會留下一些注釋(有時是不那麼友好的話)，不要生氣。他並不是在說你是一個很爛的程式設計師。這不是他的本意，也不是代碼審查的目 的。他的所作所為是在批評代碼(而不是作者)。代碼審查是針對代碼，不是針對你。不要把代碼審查當成互相諷刺的論壇和相互批判的工具。當你寫審查注釋時， 努力保持不要粗魯，也不要太苛刻。努力站在作者的立場上看待這些代碼。
總結一下，很多種錯誤都會使代碼審查變味。上面4種是我經歷過或預料到的，請警惕。我承諾還會寫一篇描述「代碼審查是來…..」的文章。
如果你想嘗試一種代碼審查工具，請訪問codebrag.com，這是我們的經驗和實踐的成果。