你的代码或许不会在第一天就被同行评审，但这种事情头几个月内肯定会发生。

　　许多程序员厌恶、憎恨或双倍不喜欢代码评审，但实在没有理由去恨它们。其实，有经验的程序员还期待代码审核—我们很快将看到原因。

　　人和观点

　　如此多的代码审核以失败告终的原因在于：程序员将他们代码的价值和自身的价值画上等号。当审核者指出代码中的问题时，程序员将之视为一种攻击，并且采取防卫姿态，整件事情于是很快急转而下。

　　我们要清楚地认识到这一点：审核者将找出你代码中的错误。我敢保证，绝对会找到。但那并不意味着你的技术就很糟糕。改进的空间总是存在；或者对于你的代码该如何书写，至少存在不同观点。将代码评审核为一种开放式讨论，而不是一种你是被告的审判。

　　“错误”的范围可以从Bug到风格问题。Bug简单，你必须修复它们。每个人，菜鸟和专家都一样，不时会犯错，因此屋子里没人会认为你就是白痴。把问题记下来，然后继续前进。

　　更具有争议性的问题在面对风格问题时产生。可能你正在使用带计数器的循环，资深程序员审核你的工作时建议换成迭代器。这表明你的代码有错和该建议正确吗？不，风格问题没有那么绝对。

　　既然这是一场开放式的讨论，那就可以深入探讨这个建议的优点。审核者可能会说：“使用迭代器消除了差一（off-by-one）错误的可能性。”不要产生防御心理并争辩：“可我的循环没有差一问题！”审核者已经看到了。他想说的是：换种方法消除那种可能性是好风格。

　　一旦理解了审核者的意思，就要感谢他的建议，记下来，继续前行。在你有时间让代码审核的紧张感消失之后，考虑你的行动计划。风格上的异议会因为人身攻击引发争议；若在没有他人在场的情况下考虑这种异议的优点，你可能会发现审核者有一定的道理。

　　观点是本质：无关乎你和审核者的对错。它关乎好的代码和更好的代码。

　　形式

　　我将描述我看到过的代码审核的形式，并就它们给你一些提示。

　　非正式审核

　　你经常会被某些东西难住，这时需要有人来帮你解决它。或者可能是，你发现这是个好的解决方案，但你拿不准。去找个更有经验的程序员。就算是脾气再不好的人这时也往往会先忍住，被征求意见的恭维甚至能软化脾气最差的人。

　　伙伴系统

　　有些项目要求凡是要检入代码库的代码都要有“伙伴”签字。你完成了变更，也测试过了。现在，你需要有人在检入前对其评审。不要只找跟你要好的同事，他们会对你写的任何东西大开绿灯。去找你更改部分的领域专家。要是找不到，那就去找一个跟你不太熟的同事。

　　将伙伴系统作为一种让更多人熟悉你工作的方法。尤其当你是新人的时候，没有什么比用代码来建立自己的公信力更好的方式了。它不需要是耀眼、巧思、别出心裁的代码—只需要是可靠的代码。确保人们可以定期地见到它。

　　高层审核

　　这往往是多人参加的有投影仪的正式审核会。往往审核数周的工作成果，但以一种高层次的观点来看。你解释设计，解释它如何转换到代码，然后审核代码的关键部分。这是一次讨论设计和风格的机会。准备好挨批评，记住在前面的“人和观点”一节讨论过的问题。

　　作为审核员，我最喜欢的问题是“给我看测试”。我对我领导的每个项目都要求自动化测试，因此，要是对这个问题的反应是一片茫然，审核就结束了，我们将在下周安排一次新的审核。不管怎样，有经验的程序员会从浏览测试开始审核。没有什么比展示测试更能确立对你代码的信心了。

　　逐行审核

　　最无聊、让人觉得压抑的代码审核就是每人逐行检查代码。实际上，这类审核往往是为那些已经成为灾难的代码准备的。（最好不是你的代码。）假设你处于捉虫模式，对每行代码都要问：这行的假设是什么？哪些方法会让它失败？万一失败了会怎样？

　　如何避免这种对你代码的逐行审核？简单：让你的代码早点审核，而且经常审核。采用非正式或伙伴系统，或安排组内审核。我一开始说过：有经验的程序员渴望代码审核。这是因为他们更愿意早点得到反馈，避免陷入需要逐行审核的麻烦里。