代码审核是软件开发文化的主要组成。这项实践尤其重要，因为我们的目标是交付可靠的产品，而所有伟大的产品都离不开整洁的代码。如果你没有实施代码审核，或者你觉得可以进一步提高代码审核水平，快让代码审核来助力。

代码审核的内容

查看代码的结构、风格、逻辑、性能、测试覆盖率、设计、可读性、功能性。虽然结构与逻辑的检查可以交给自动检查，但功能与设计则需要人工审查。

带着问题审核代码可以让你关注正确的问题。例如，在审核代码时，你需要考虑以下几个问题：

在代码审核之前完成构建与测试

不要假定代码可以正常运行，你应该自行完成构建与测试。在测试代码的时候，确保你的构建很正确。如果项目有构建系统，你应该使用。如果持续构建系统报告说代码可以成功构建，那么你也应该可以做到。注意，如果 CI 构建失败，你应该要求代码构建成功，才能发布。

在编译完代码后，你应该运行测试。

注释很重要

每个逻辑语句都应该通过注释描述程序员的意图。假设你从事的项目遵守这项约定，但你没有看到注释，那么就应该要求他们添加上去。只是添加注释还不够，注释必须说清楚代码的实际意图。

提供有帮助的反馈

建设性的反馈才是代码审核的核心。如果不想做陈述的话，你可以提问。在提出建设性反馈的同时，不要忘记给予赞扬。当面给出反馈有助于正确地沟通。代码需要审核，而你需要审核同事的代码。将审核作为一种学习的过程，对每个人都有好处。

考虑代码在生产环境中的运行

设计很重要，集成也很重要。这些代码如何在实际的系统中运行？它怎样处理错误的输入以及用户错误？它可以很好地兼容其他代码吗？简而言之，代码必须严谨。

检查文档、测试与构建文件

好的代码不仅包括代码，还有周围所有的一切。每次改版都应该包含下列各项：

覆盖新代码的测试。严格审核这些代码，确保如果有问题的话，测试会失败。

新代码的文档。良好的代码离不开良好的文档。不要将文档工作留到后面再说，文档本身应该一起出现在新版本中。

README更新。README.md、BUILDING.md、CHANGELOG.md等文件应该反映出最新的变化。实际上，这些文件很少需要变化，但你应该确保这些文件的更新。

提建议的时候应该说明优先级

代码应该：

最终，代码都应该满足上述要求，但是满足的顺序也很重要。如果代码不能正常运行，那就不要着急担心风格的问题了。同理，如果代码有问题，或者风格很糟糕，那么优化只会让情况更糟。

落实审核结果

在提出修改意见之后，你应该准备好再审核一次。确保必要的修改都落实了，而且所有发现的问题都得到了解决。

另外，你需要确保投入足够的精力跟进后续的审核，就像是第一次审核一样。重新核对此处介绍的准则。

审核人员也不完美

审核代码是一项艰巨的任务，所以不要忘记审核人员也不完美。你可能会漏掉一些问题，发现不了一些 bug，性能缺陷也可能进入生产环境……简单来说，出现有问题的代码也很正常！

如果你不熟悉代码或者概念，则可以要求其他审核人员提供反馈，但是不要害怕担任审核的工作。四只眼睛总比两只眼睛看得清楚。

如果你发现自己在审核中犯了错，最佳处理方式是承认错误。在审核系统的注释中说明，或填写问题/bug票。代码审核检查列表：代码的格式、架构、非功能性需求、面对对象分析以及设计原则是关键因素，可以确保新产品开发的的可维护性、可读性、可扩展性以及实用性。

如下代码审核检查列表可以让你了解到，在代码审核期间，你需要考虑哪些方面：

初级问题

中级问题

高级问题

1. 代码审核的副作用

然而，代码审核也有一定的副作用，每个开发人员都应该仔细考虑。

2. 对事不对人

代码审核最常见的问题之一是，有时人们会觉得被某些评价冒犯到了。这也不奇怪，代码审核是提供反馈的机会，难免会以批评的形式出现，而批评本身就很棘手。审核代码的人一不小心就会给出批评，而批评很容易被误解成人身攻击。

建设性的批评有助于成长，但是为了有效地提出批评，提出方与接收方都应该谨慎地沟通。

3. 语气

提出意见的人必须注意语气。虽然有些批评并不是针对个人，但是往往会被误解。

4. 错误的时间，错误的场合

有时，代码审核意见会跑题。不是说人们讨论的话题不对，而是说他们讨论的问题不属于代码审核的范畴。

5. 风格

例如，很多PR的评论都为多少个空格而争论不休。其实，这种问题完全可以通过编程准则消灭于无形。

6. 架构

还有一种情况是，代码审核的评论涉及系统的更高层，可能需要展开架构层面的讨论。如果代码中存在任何架构问题，审核人员当然有责任将其找出来。最终的代码审核并不是全面讨论如何解决问题的最佳场所。理想情况下，这些问题应该在动手编写代码之前就得到了解决。

7. 忽视

代码审核还有一个常见的问题是：人们不及时地审核。PR在提交之后需要等很久才能得到评论。出现这种情况的原因有很多：

文章部分素材来源：CSDN