代码质量与安全 | 实践“边写边清理”，您需要做好这两件事：质量配置文件和质量门

“边写边清理”是一种让开发人员能专注于新代码，以微小的投资收获巨大代码质量影响的一种方法。作为开发人员，您只需要确保今天编写的代码干净且安全，而无需负责清理其他人的代码。

本文中，我们将重点关注规则、质量配置文件和质量门——有效实践“边写边清理”策略的重要基石。阅读本文后，您将更好地了解它们是什么，以及如何使用它们来实现干净、高质量的代码！ 

作为 SonarQube 授权合作伙伴，创实信息持续关注代码质量与安全领域，为中国用户带来全球范围内的优秀解决方案，帮助企业实现开发安全运营一体化。

本篇文章将重点关注规则、质量配置文件和质量门，因为这些元素是有效的“边写边清理”策略的基石。阅读本文后，您将更好地了解它们是什么，以及如何使用它们来实现干净、高质量的代码！

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

在讨论质量配置文件和质量门之前，有必要先了解我们为什么要花大力气来创建这个基石功能。答案很简单，因为它可以帮助我们回答一个基本且非常重要的问题：您编写了一些新的/更改的代码，它们是可以接受的吗？

当然可以接受！我们有一个确定的方法，请继续阅读。

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

规则是质量配置文件最基本的元素，每种语言都需要一个质量配置文件。对于给定的语言，我们可能有选择性的在分析过程中应用某些规则。质量配置文件是一个规则容器，它决定了哪些规则在分析过程中被激活和应用，哪些被停用。选择应用哪些规则由您和您的队友来决定。这里有两条路径供您选择：1) 使用内置、默认的质量配置文件，称为 Sonar 方式；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 产品营销经理

文章来源：blog.sonarsource.com/clean_coding-quality_profile_quality_gate_guidance/