关于代码质量:代码质量与安全-实践边写边清理您需要做好这两件事质量配置文件和质量门

2次阅读

共计 4132 个字符,预计需要花费 11 分钟才能阅读完成。

“边写边清理”是一种让开发人员能专一于新代码,以渺小的投资播种微小代码品质影响的一种办法。作为开发人员,您只须要确保明天编写的代码洁净且平安,而无需负责清理其他人的代码。

本文中,咱们将重点关注规定、品质配置文件和品质门——无效实际“边写边清理”策略的重要基石。浏览本文后,您将更好地理解它们是什么,以及如何应用它们来实现洁净、高质量的代码!

作为 SonarQube 受权合作伙伴,创实信息继续关注代码品质与平安畛域,为中国用户带来寰球范畴内的优良解决方案,帮忙企业实现开发平安经营一体化。

本篇文章将重点关注规定、品质配置文件和品质门,因为这些元素是无效的“边写边清理”策略的基石。浏览本文后,您将更好地理解它们是什么,以及如何应用它们来实现洁净、高质量的代码!

森林之于树木——您必须要有的全局观

在探讨品质配置文件和品质门之前,有必要先理解咱们为什么要花大力量来创立这个基石性能。答案很简略,因为它能够帮忙咱们答复一个根本且十分重要的问题:您编写了一些新的 / 更改的代码,它们是能够承受的吗?

当然能够承受!咱们有一个确定的办法,请持续浏览。

森林中的树木——规定、品质配置文件和品质门

规定是品质配置文件最根本的元素,每种语言都须要一个品质配置文件。对于给定的语言,咱们可能有选择性的在剖析过程中利用某些规定。品质配置文件是一个规定容器,它决定了哪些规定在剖析过程中被激活和利用,哪些被停用。抉择利用哪些规定由您和您的队友来决定。这里有两条门路供您抉择:1) 应用内置、默认的品质配置文件,称为 Sonar 形式;2) 自定义品质配置文件。尽管内置品质配置文件很棒,但与您的团队面对面探讨代码品质和代码安全性,并达成共识,会为您的环境带来两大影响:

  1. 如果您从未进行过这种练习,那么这是一个让每个人在同一页面上进行对话的好机会,并能分明地理解洁净、平安的编码冀望。
  2. 它造成了为每种语言构建定制品质配置文件的执行手册,并且体现您团队的现实。

例如,如果您的团队不太关怀代码异味,就能够应用 SonarQube/SonarCloud 规定标签上的分类和过滤性能,减少或缩小在品质配置文件中激活的规定。

这是 Java 的内置 Sonar 形式的品质配置文件。您能够看到,它蕴含了所有 Java 规定的不同子集。

当初,咱们有了规定容器,每种语言都有一个规定容器,称为品质配置文件。每次针对特定语言运行剖析时,该语言的品质配置文件中,所有流动规定都会利用于被剖析的代码。在幕后,通过文件扩展名进行的自动检测,能确保在剖析期间,调用了正确的品质配置文件和语言分析器。

在剖析后果中,任何违反规定的行为都会被标记为问题。不过,仅仅标记在您的代码中发现的问题,对咱们来说没有太大帮忙。在这一点上,咱们还不足以答复对于是否应该合并您的新代码或更改代码的这个问题。

咱们须要一种办法,将剖析后果与一组验收规范(也称为条件)进行比拟。这就是品质门(QG)发挥作用的中央。在 SonarSource 术语中,这些条件的执行称为品质门,实质上它是二元对抗的——要么通过,要么失败。

品质门

通过抉择一个指标,而后设置通过 / 失败阈值,品质门让你能够设置本人的代码品质和平安条件。如果品质门中的任何一个条件失败,则整个品质门将失败,你就晓得在补救之前,先不要合并代码。品质门是动静更新的,因而您会立刻晓得修复是否为您提供“绿灯”!

就像应用品质配置文件一样,您能够应用称为 Sonar 形式的内置品质门,或者依据咱们后面谈到的团队洁净、平安的编码定义来定制本人的品质门。以下示例将展现这所有是如何组合在一起的。下图显示了可靠性(bug)评级指标的计算形式。

你能够把品质门看作是一张成绩单,下面有及格或不及格的倡议。通过或失败的实质是要害,因为咱们想让通过 / 不通过的决定相对清晰,而不会产生争议。从代码品质和代码平安的角度来看,代码要么通过,要么不通过。那种认为代码 ” 足够好 ” 或 ” 我当前会修改 ” 的想法是行不通的。下图显示了在 SonarSource Java 代码分析器上,利用于新代码期的品质门(在 SonarSource,咱们对本人的产品很称心)。

有了它,当初您是品质配置文件和品质门方面的专家了。感觉还不错吧?

这里的关键在于:咱们将谋求一个牢靠、高效、可反复的流程,这个流程会在你的团队的工作流程中扎根。在您的新 / 更改代码上监控品质门将成为一种习惯,您无奈设想有一天它不再是您流程中一部分。

品质门利用

新代码期
在多数状况下会应用到品质门,其中一个重要的状况是剖析新代码。SonarQube/SonarCloud 利用一个叫新代码期的概念,默认状况下,SonarQube 的新代码期被设置为“以前的版本”。新代码期的定义是涵盖你在短期内所做的工作。兴许这是以后的 sprint 或应用程序的下一个版本。尽管 SonarQube/SonarCloud 能够剖析您的整个代码库,但这些信息尽管很乏味,却不能立刻发挥作用,因为它的可操作性低。你可能不会停下手头上的事去重构代码库。事实上,在最后扫描完所有我的项目后,返回的“成绩单”可能会令人十分丧气!不过这没什么大不了,罗马不是一天建成的,您的团队也无奈在一夜之间就解决过来数周甚至数年累积的问题。
然而,与以后软件版本或以后 sprint 相干的代码是可操作性十分强的,这也是您应该集中精力进行代码品质修复工作的中央!有许多办法能够定义您的新代码期,例如与参考分支、先前的剖析或指定天数(如冲刺长度)进行比拟,找出最适宜您团队的工作形式。

这种办法突出了“边写边清理”方法论的魅力——通过关注新代码期并只提交合格的代码,您最终将重构并清理代码库中所有重要的局部。

拉取 | 合并申请
品质门的另一个重要用处是针对拉取 / 合并申请。咱们曾经确定,只有可操作的指标才与代码品质无关,而拉取申请是利用品质门的现实场合。以下是品质门集成到工作流程中的样子:

GitHub、Bitbucket、Azure DevOps 和 GitLab 反对 SonarQube/SonarCloud 品质门状态批示。上面是 GitHub 拉取申请上一个很好的绿色品质门的状态批示。

拉取申请具备极强的可操作性,代表着您正在创立 / 更改的最间接的代码,因而放弃代码洁净和平安是您能够做的第一件事,这将进步我的项目和应用程序的品质和安全性。

正确的品质配置文件保护

尽管对于品质配置文件保护和新数据输出的探讨超出了本文探讨的范畴,但回顾一下基础知识还是很有用的。如果您抉择保持应用内置 Sonar 形式的品质配置文件,则无需保护。装置最新版本的 SonarQube 会自动更新所有内置语言的品质配置文件。对于 SonarCloud,品质配置文件是由 SonarSource 定期更新的。

* 您的任何保留继承的自定义品质配置文件也会更新(在上面的“品质配置文件扩大”局部中介绍)

另一方面,如果您和您的团队决定定制语言品质配置文件的一部分,则须要牢记一些重要的保护注意事项。

定制品质配置文件

有两种办法:复制或扩大。品质配置文件复制要执行复制,您只需复制一个内置配置文件,给它起一个惟一的名称,而后将其设为您本人的。当您复制一个品质配置文件时,能够自在激活 / 停用原始品质配置文件中的规定。复制品质配置文件将毁坏内置配置文件的继承关系,未来对父级品质配置文件的任何扭转都不会被复制的品质配置文件所接管。为了解决这个问题,您须要定期对该语言的内置品质配置文件进行查看,以使其达到最新状态。SonarQube/SonarCloud 中蕴含一个比拟性能,使这种定期同步更无效。

请记住:如果您走的是复制路线,您将签订一个定期的品质配置文件保护和供应。也就是说,如果你不保护你的品质配置文件,那么每次产品公布 / 更新都会变得越来越过期。

品质配置文件扩大 

当您扩大品质配置文件时,子级品质配置文件会接管父级品质配置文件的将来更改,然而,您无奈禁用规定。当您想要从一个基线品质配置文件扩大并从继承更改时,扩大品质配置文件很有用。例如,你想要一个组织品质配置文件,但你想在将来继承增加到 Sonar 形式(内置品质配置文件)的新规定,你要扩大而不是复制它。扩大品质配置文件时,您能够激活在您继承的配置文件中未激活的规定。这是一种更严格的形式,不会放松来自父级品质配置文件的规定。

如果您认为停用某些规定对您的组织有意义,一种办法是创立一个顶级配置文件作为“Sonar 形式”的正本。复制能够让你停用你感觉不适合的货色。从这个正本中,你能够依据须要创立特定的部门 / 团队级别的配置文件。这种“嵌套”办法为您提供了两败俱伤的益处——复制品质配置文件容许您强制执行组织范畴的规范,而扩大品质配置文件容许你对团队进行更精密的治理。因为设置继承的形式,您只需定期同步父级复制配置文件,更新就会逐级传递到扩大品质配置文件。上面的例子展现了如何嵌套品质配置文件,满足团队的需要。

无论哪种状况,如果您抉择自定义品质配置文件,必须思考更改将对开发团队产生的影响以及异议。例如,关上太多规定可能会导致开发人员疏忽问题,毁坏工具的有效性。

总结

最初,我催促您记住始终以来强调的——无效的代码品质和平安实际应该成为一种习惯,并很好地集成到您团队的工作流程中。它不应该是破坏性的,或要求开发人员成为代码品质和平安专家。品质门将这种一致性与清晰的通过 / 不通过信号一起带入工作流程。

确定团队的代码品质和安全性是很重要的。你的组织的执行手册是什么?当然,每个人都能够对代码品质发表意见,然而,这最终是没用的,因为它不通明,也不容易被所有的团队成员所承受。您不能指望人们恪守一个不通明或基于个体常识的规范。有了这个代码品质 “ 执行手册 ”,对新招聘的员工和老手开发者来说特地有价值,因为它是一个明确的冀望指标。

在团队探讨的期间征求意见,这样就能建设一个造成你的品质配置文件和品质门的规范。探讨它,批准它并采纳它,而后,您就能够依附 SonarSource 和品质门来执行它。

想要体验 SonarQube 或试用 SonarCloud,请分割 SonarQube 中国官网受权合作伙伴——创实,咱们提供 SonarQube 产品的征询、销售、施行、培训及技术支持服务。

作者简介:

克林特·卡梅隆
Sonar 产品营销经理

正文完
 0