首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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

编译 | 弯月    责编 | 丁恩华

头图 | 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元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券