在我们公司里要执行代码审查。这是我们每天的例行工作。事实上，今天的我们正是从这种一直坚持探索的漫长道路上走出来的。我们尝试各种技术、方法和工具，直到我们走到今天的成就(但这并不是说我们就此停步)。

在这旅途中，我们发现了很多的陷阱和危险，它们等待新手们上钩。这篇文章就是关于它们的：代码审查中的陷阱和误解。

代码控制：

很多公司都把代码审查当成控制代码的方法。很多这样的公司都使用预提交策略。这种策略大多时候都是开源项目中使用，因为会有成百上千的提交者。可在一般的公司里，很少会有这种情况。如果你雇用一个人，这意味这你要完全信任他，允许他将代码提交到代码库里。我知道有些公司会忍不住制定一些规程，要求程序员在提交代码前必须进行“审查”和“批准”，但这并不能保证代码的质量。而且，程序员很快就会把这种代码审查当作一种“愚蠢”的公司形式过程，会开始抵制它(例如，每月改一次密码。例如，使用像mypass1,mypass2等的密码)。

审判厅：

不要把代码审查当成寻找替罪羊和追究责任的工具。比如说，这有一个错误，你找到“审查”这段代码的人，并责备他没有发现这个问题。这种事情会给公司里的开发工作带来严重的影响。人们会挑出每个分号放置不正确的地方，因为他们担心会被当成替罪羊。团队成员开始缺乏信心，并最终失去互信。

责任任务：

不要过分要求程序员做代码审查。如果你强迫他们每天做一小时的代码审查，他们很快就会痛恨它，把它当成一种无趣的任务。代码审查是一种学习，是表扬，是获得反馈，是一种十分社交性的活动。代码审查应该是有趣的，不要让它变的无聊。

我和我的代码

如果你的代码被某人审查，他会留下一些注释(有时是不那么友好的话)，不要生气。他并不是在说你是一个很烂的程序员。这不是他的本意，也不是代码审查的目的。他的所作所为是在批评代码(而不是作者)。代码审查是针对代码，不是针对你。不要把代码审查当成互相讽刺的论坛和相互批判的工具。当你写审查注释时，努力保持不要粗鲁，也不要太苛刻。努力站在作者的立场上看待这些代码。

总结一下，很多种错误都会使代码审查变味。上面4种是我经历过或预料到的，请警惕。我承诺还会写一篇描述“代码审查是来…..”的文章。

如果你想尝试一种代码审查工具，请访问codebrag.com，这是我们的经验和实践的成果。