每次搞代码审查的时候，我总会听到自己的同事们的抱怨：

“为什么要做代码审查啊?”

“我不需要代码审查，这是在浪费时间。。”

“之所以时间推迟，就是因为同事还在审查我的代码。”

“竟然有同事要求我改代码，我这么完美的代码怎么会需要改呢?”

代码审查的重要性

任何一个优秀软件的程序员首要的工作目标就是不断提高自己的工作质量，但提高一个软件的工作质量不是一个人所能完成，需要团队成员的齐心协力，而代码审查是提升软件质量必不可少的一个环节，代码审查有以下作用：

可以从多个角度发现软件缺陷并且寻找到更好的办法。

可以使其他人熟悉你的代码。

可以通过自己的代码培训新员工。

迫使程序员更认真的写代码、解决代码中的问题，以免在审查时被别人揪出来。

代码审查的彻底性

但审查不是随意的浏览一遍，需要在上面花费一定的时间和精力，否则很难有效果。

我认为程序员大概要花 25% 的时间在代码审查上。即如果一个程序员需要用两天时间来实现某个程式，那么就应该花大约 4 小时进行审查。

当然时间并不是最重要的，关键是要看你能否正确审查代码。你必须了解你正在审查的代码。这意味着你不仅仅要知道它的的语法，还必须理解代码是如何融入应用程序这个大环境下，成为组件或库的一部分。如果你不能把握每一行代码的含义，那么你的审查就不到位，也不会非常有价值。这也是为什么良好执行的 代码审查，大多不可能迅速被完成：因为我们需要时间来研究各种代码，如能触发给定功能以确保第三方 API 正确使用的代码。

在审查时，除了要寻找代码缺陷和其他问题，你还应该确保：

囊括了所有必要的测试。

已经写入了恰当的设计文档。

即使是那些擅于写测试和文档的程序员，也会在改变代码的时候忘记更新。代码评审时就应该确保这些资料不会随着时间而变得毫无用处。

代码审查的适度性

当然，重视审查并不是要你因为审查工作而导致自己无法安心进行编程，程序员应该养成自己的工作习惯，在某个特定的时间段来进行审查工作，例如，我们可以在早上代码审查，在开始自己的开发工作之前先搞定审查任务。当然你也可以午饭前后或者是一天结束之时审查代码。总之，你应该将代码当作是日常工作的一部分，而不是工作的拖累。

代码审查的责任和沟通

如果真的出现了代码审查堆积的问题，那需要负责任的人绝非审查人员一个人，如果你的同事用一个星期的时间为一个大型软件添加了一堆乱七八糟的代码，那么想想就觉得可怕，因为那会使得发布的补丁变得很难审查，让更多的内容一点点的钻研和理解，浪费大家的时间，这就是写代码的程序员的问题了。

在编写可审查的代码之前，我们要提前做好准备工作。如果需要做一些棘手的架构决策，最好先和审查人员进行沟通。这将能让你的代码更容易受人理解，因为他们提前已经知道你的想法和路。这样也可以避免如果审查人员之后提出一个截然不同又更好的方法，导致你不得不重写一大片代码的情况。

项目架构应该在设计文档中详细描述。这点很重要，因为它能让新的项目人员更快地理解现有的代码库，还能有助于审查人员更好地完成他们的工作。此外，单元测试能让审查人员更好地理解各个组件的使用。

编写易审查代码的重要方法之一就是给你的代码审查做注释。这需要你自己预先审查过，然后在你认为有助于审查人员理解的地方添加注释。我发现，注释后的代码审查所需的时间相对较短(通常只需几分钟)。当然，代码注释还是应该酌情使用。此外，有研究表明，程序员自己在给代码注释的时候也会发现许多存在的缺陷。

代码重构时的审查

有的时候，我们不得不重构代码库，如果是一个大型的程序，那我们可能要花费几天甚至更多的时间，期间还会产生大量的补丁，这时候想完成标准流程的代码审查几乎是一件不可能的事情。

这时候最好的解决办法就是一个阶段一个阶段逐步重构代码。先给定一个合理范围，确定相应的代码库，然后朝着目标方向做整改和重构。第一部分完成之后，审查并发布，然后进行第二阶段的重构……，直到全部完成。这种阶段式的方法可能并不总是可行的，但是如果我们在思考和规划时使用这样的方法，可以避免重构时大规模的单片补 丁。当然这种方式可能需要的重构时间更多，但是也会产出更高质量的代码，以及更加轻松的审查过程。

如果增量重构代码还是不可行，那么还有一个解决办法就是结对编程。

代码审查的争执解决

我相信团队中的每个成员都是人才，但是这也很容易导致在面对特定的编码问题时，会出现意见分歧的情况。作为程序员，我们应该保持开放的态度，并且也要能虚心接受审查人员给出的不同意见。

而作为审查人员，说话要委婉。在提建议之前，先考虑一下你的意见是否真的更好或者仅仅只是因为品味不同而已。如果你选择的代码区域确实需要改进的，那么整个说服过程就会简单得多。并且话要这样讲，“这里还值得考虑一下……”，“有人建议说……”，而不是“我闭着眼睛写的算法也能比你的高效。”

当然如果你们双方都不肯妥协的话，可以要求你们都尊重的程序员来看一看，给出他的意见。