翻车事故频发，原来是开发者漏了这一步！
编译 | 弯月? ??责编 | 丁恩华
头图?|?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在提交之后需要等很久才能得到评论。出现这种情况的原因有很多：
代码变更量过大。当代码变更量过大时，审核代码的人会感觉到压力。变更量完全由编写的人决定。当然，有时候无法避免大型变更。遇到这种情况，应该组织一次面对面的代码审核会议。这种方式比一长串的评论更有效。
代码审核的形式。事实上，无论代码变更量有多少，有时就应该组织代码审核会议。虽然花费的时间更多，但是可以及时地获得有效的反馈。
总结
一旦建立切实的流程后，代码审核就会变成学习的良机，整体的代码质量也会得到提升。持续成功需要团队贯彻流程，并教导初级开发，但是，为了培养健康的代码审核文化，一切努力都值得。
- 发表于:
- 原文链接：https://kuaibao.qq.com/s/20210121A08O6800?refer=cp_1026
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
