清洁代码能够让软件开发工作变得更简单、更有趣。因为如果代码不够清洁，开发人员将花费很多时间在解决编码问题上，使他们无法将精力投入开发新代码、解决其他更有趣的问题上。
那么，该如何将清洁代码标准扩展到整个企业呢？阅读本篇文章，您将了解到一些工具的详细介绍，有助于您扩展清洁代码。
创实信息作为SonarQube授权合作伙伴，持续关注代码质量与安全领域的最新动态与实践，为中国用户带来全球范围内的优秀解决方案，帮助企业实现开发安全运营一体化。
代码是软件的核心，决定了软件的特性和性能。
清洁代码让您的开发团队更容易修改和优化软件，因为这不会有任何问题。您无需把时间浪费在修改对于您业务来说昂贵且具有破坏性的复杂或僵化的代码上。
清洁代码有助于让您的软件继续成为资产——而非负债——并且成为让业务走向成功的关键驱动力。
一个真正的针对软件开发的清洁代码解决方案，应该是可维护、可靠且安全的。但是，什么样的工具可以让您可以在整个企业范围内扩展实施清洁代码标准呢？本篇文章将详细介绍其中一些工具。
质量配置文件
质量配置文件是软件开发项目配置的一个关键部分。它们定义了代码分析过程中要应用的一组规则。
每个项目都有一个针对每种受支持语言的质量配置文件。当分析一个项目时，您应该能够确定使用了哪些语言，并为该特定项目中的每种语言使用有效的质量配置文件。
内置和默认配置文件
Sonar为每种支持的语言定义了一个内置质量配置文件，称为Sonar方式（Sonar Way）配置文件。Sonar方式激活了一组适用于大多数项目的规则——它代表Sonar的建议，并且在每个版本中都会更新，包括新的规则。
在一个新设置的实例中，Sonar方式配置文件是每种语言的默认设置。如果在项目层面没有明确定义其他配置文件，则默认配置文件用于该语言。某一特定语言的默认配置文件可以被改变。
自定义质量配置文件
Sonar方式配置文件广泛适用于大多数项目，但它只是作为一个起点。在大多数情况下，随着您的组织使用Sonar的进展，您将希望调整配置文件。
如果您有多个项目，那可能还需要为每个项目设置不同的配置文件。您可能会遇到以下两种情况：
- 每个项目都有不同的技术需求；
- 您希望对某些项目的要求比对其他的更高。
关于自定义质量配置文件，需要注意以下几点：
- 确保定期重新访问自定义的质量配置文件，尤其是在升级包括新规则和消除已弃用规则之后；
- 尽量减少质量配置文件的数量，这样您就不会陷入每个项目都遵循不同规则集的情况，也就是说，在整个组织内保持一致性。
质量门限
质量门限是通过回答一个问题在您的组织中执行质量政策的，这个问题就是：我的项目准备好发布了吗？
为了回答这个问题，您需要定义一组衡量项目的条件。例如：
- 没有新的拦截器问题；
- 新代码的代码覆盖率大于80%。
理想情况下，所有项目都使用相同的质量门限，但这并不总是可行的。例如，您可能会发现：
- 技术实施因应用程序而异（您可能对Web或Java应用的新代码的代码覆盖率要求不一样）；
- 您希望确保对某些应用程序（例如内部框架）的要求更严格。
您可以根据需要定义和管理任意数量的质量门限，因此，您可以将质量门限的条件重新集中在应该立即解决的问题上。
通知
由于Sonar的通知机制，当一个质量门限失败时，你可以得到通知。这只需要您订阅所有项目或你感兴趣的一组项目的质量门限新状态通知。有几种方法可以获得质量门限失败的通知，但最常见的是通过电子邮件。
在每次分析结束时，Sonar都会为每个订阅用户计算通知。然后，通过电子邮件以异步方式发送这些通知。
只有自己订阅的用户才会收到通知。如果您坚信一个用户应该一直收到通知，那么是时候练习一下说服的艺术了。
企业报告
详细的项目规划和开发团队成员之间的协作是让软件开发项目得以推进的关键因素。重要的是，您的开发人员需要确保团队在代码分析时对健康代码的定义是一致的。
Sonar的项目报告为开发团队提供了当前的质量门限状态和任何有可能导致失败的条件，以及新代码的主要指标值。有了精心定义的指标和团队达成的共识，代码质量得到保持，项目得以按时交付。
开发团队可以对项目进行分组，以映射到您的企业架构。项目组合让他们能够立即了解整个部门所有项目的健康状况，包括项目的可发布性。
通过Sonar，开发团队可以生成、导出和预定PDF格式的报告，确保关键指标对所有利益相关者可见。
结论
当您需要将清洁代码标准扩展到整个企业时，请先了解本博客中描述的工具的价值。有了这个基础，您可以让您的软件成为一种资产，并且成为业务走向成功的关键。
作者介绍：
布鲁斯赫伯特
Sonar产品营销经理