程式碼審查不是用來……

　　在我們公司裡要執行程式碼審查。這是我們每天的例行工作。事實上，今天的我們正是從這種一直堅持探索的漫長道路上走出來的。我們嘗試各種技術、方法和工具，直到我們走到今天的成就(但這並不是說我們就此停步)。

　　在這旅途中，我們發現了很多的陷阱和危險，它們等待新手們上鉤。這篇文章就是關於它們的：程式碼審查中的陷阱和誤解。

　　程式碼控制：

　　很多公司都把程式碼審查當成控制程式碼的方法。很多這樣的公司都使用預提交策略。這種策略大多時候都是開源專案中使用，因為會有成百上千的提交者。可在一般的公司裡，很少會有這種情況。如果你僱用一個人，這意味這你要完全信任他，允許他將程式碼提交到程式碼庫裡。我知道有些公司會忍不住制定一些規程，要求程式設計師在提交程式碼前必須進行“審查”和“批准”，但這並不能保證程式碼的質量。而且，程式設計師很快就會把這種程式碼審查當作一種“愚蠢”的公司形式過程，會開始抵制它(例如，每月改一次密碼。例如，使用像mypass1,mypass2等的密碼)。

　　審判廳：

　　不要把程式碼審查當成尋找替罪羊和追究責任的工具。比如說，這有一個錯誤，你找到“審查”這段程式碼的人，並責備他沒有發現這個問題。這種事情會給公司裡的開發工作帶來嚴重的影響。人們會挑出每個分號放置不正確的地方，因為他們擔心會被當成替罪羊。團隊成員開始缺乏信心，並最終失去互信。

　　責任任務：

　　不要過分要求程式設計師做程式碼審查。如果你強迫他們每天做一小時的程式碼審查，他們很快就會痛恨它，把它當成一種無趣的任務。程式碼審查是一種學習，是表揚，是獲得反饋，是一種十分社交性的活動。程式碼審查應該是有趣的，不要讓它變的無聊。

　　我和我的程式碼

　　如果你的程式碼被某人審查，他會留下一些註釋(有時是不那麼友好的話)，不要生氣。他並不是在說你是一個很爛的程式設計師。這不是他的本意，也不是程式碼審查的目的。他的所作所為是在批評程式碼(而不是作者)。程式碼審查是針對程式碼，不是針對你。不要把程式碼審查當成互相諷刺的論壇和相互批判的工具。當你寫審查註釋時，努力保持不要粗魯，也不要太苛刻。努力站在作者的立場上看待這些程式碼。

　　總結一下，很多種錯誤都會使程式碼審查變味。上面4種是我經歷過或預料到的，請警惕。我承諾還會寫一篇描述“程式碼審查是來…..”的文章。

　　如果你想嘗試一種程式碼審查工具，請訪問codebrag.com，這是我們的經驗和實踐的成果。

　　英文原文：Code Review is not about...