翻车事故频发，原来是开发者漏了这一步！

编译 | 弯月    责编 | 丁恩华

头图 | CSDN 下载自东方IC

出品 | CSDN（ID：CSDNnews）

在本文中，我们就来分享一下代码审核的最佳实践，以及为什么代码审核对于团队与产品的成功至关重要。如果你没有实施代码审核，或者你觉得可以进一步提高代码审核水平，我们希望本文对你有所帮助！

为什么要实施代码审核？

代码审核是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，目的是找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。如果你想检查初级开发的代码、提高代码可读性、在团队内分享知识，那么应该优先考虑代码审核。以下是我们的代码审核准则。

代码审核的内容

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

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

我理解代码的功能吗？

代码的运行方式符合我的预期吗？

代码满足了项目需求吗？

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

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

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

注释很重要

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

提供有帮助的反馈

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

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

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

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

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

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

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

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

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

代码应该：

第一，功能优先；

第二，整洁且易于维护；

第三，优化。

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

落实审核结果

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

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

审核人员也不完美

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

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

如果你发现自己在审核中犯了错，最佳处理方式是承认错误。在审核系统的注释中说明，或填写问题/bug票。

代码审核检查列表

代码的格式、架构、非功能性需求、面对对象分析以及设计原则是关键因素，可以确保新产品开发的的可维护性、可读性、可扩展性以及实用性。

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

初级问题

文档：编程标准是否要求注释，代码中有注释吗？注释正确吗？是否有附加价值？是否有人复制粘贴了一块代码，却忘记了更新注释？

Lint：简单或常见的错误；不符合最佳实践，或者不符合语言或框架推荐的风格。

编程标准：团队或公司是否有一套编程准则或规定？这些代码符合这些标准吗？

无意中留下来的代码：未使用的变量，需要完成的工作列表。代码被注释出去了，但没有删除。

语言惯例：代码是否符合语言和框架的惯例？

风格的统一性：这些代码的风格是否与其他代码统一？

格式

拼写

中级问题

吹毛求疵：感觉不太对的地方。代码看起来有点取巧或者像权宜之计。虽然可以正常工作，但是为了以防万一，你应该了解代码背后的思想。最后，你需要添加注释，否则下一个阅读代码的人也会觉得有点奇怪。

常见的误区：即你从以往的挫折中学到的经验教训。可能是某个框架、库或者共享组件不是特别可靠或实用。也许是某个客户提出了独特的要求。

可读性与可维护性：半年后还能读懂这些代码吗？如果原本的作者离开公司，你可以维护和更新这些代码吗？

命名：函数/方法/类的命名恰当吗？它们的用途清楚吗？在不看注释的情况下，能够明白方法的用途吗？

方式过于陈旧：最佳实践会随着应用程序的生命周期发生变化。有时，你甚至意识不到自己采用了某种过时的方法，直到在代码审核中被发现。

重复发明轮子：这个任务可以利用某些已有的代码完成。你可以重新实现一些工具代码，或者也可以利用共享库。

复杂度：代码太过于复杂，难以理解。所有功能都被塞到了几个巨型的类中，或者分散到太多类中，而这些类之间的联系也非常薄弱。

不恰当的耦合：这段代码与其他代码有连接，但这种耦合不恰当。可能是因为某个常用的库组件与它的消费者之间存在紧密的耦合。

面向公众的问题：API中的拼写错误，或者公共API的URL结构不符合准则。

覆盖率：单元测试是否覆盖了新功能？还有其他需要覆盖的重大测试用例吗？

方法的统一性：同一个区域的代码使用了两种不同的方法处理同一个问题。

极端情况：在某些情况下，这段代码可能会出问题或者出现未定义的行为吗？

性能：这段代码进入生产环境后会引发问题吗？

高级问题

引入新方法：PR引入了新模式、库或者工具。这种方法合理吗？有文档记录吗？我们需要采用这种新方式吗？这种新方法增加的工作量值得吗？

征兆和设计模式：代码结构不合理，或者代码出现了不好的征兆。可能是因为应用的模式不正确，或者可能使用其他模式更好。

不符合需求：代码没有解决应该解决的问题，或者没有解决业务需求。

镀金：为了将来的稳定性，代码变更涉及太多额外的代码，但你可能并不需要。

架构问题：在深入细节之前，先看看整体的架构是否正确。

Bug

1. 代码审核的副作用

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

2. 对事不对人

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

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

3. 语气

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

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

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

5. 风格

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

6. 架构

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

7. 忽视

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

代码变更量过大。当代码变更量过大时，审核代码的人会感觉到压力。变更量完全由编写的人决定。当然，有时候无法避免大型变更。遇到这种情况，应该组织一次面对面的代码审核会议。这种方式比一长串的评论更有效。

代码审核的形式。事实上，无论代码变更量有多少，有时就应该组织代码审核会议。虽然花费的时间更多，但是可以及时地获得有效的反馈。

总结

一旦建立切实的流程后，代码审核就会变成学习的良机，整体的代码质量也会得到提升。持续成功需要团队贯彻流程，并教导初级开发，但是，为了培养健康的代码审核文化，一切努力都值得。