暴君专栏和谐按钮_质量工具：卑微的仆人还是暴君？

暴君专栏和谐按钮

我一直是软件内部质量的热心拥护者，因为根据我的各种经验，我需要维护的代码库不只这些。 我相信，高质量的工具可以提高代码的内部质量，从而从长远来看降低维护成本。 但是，我不认为此类工具是实现这一目标的唯一方法-我还是代码审查的坚定支持者。

关于质量工具，我从Checkstyle开始，然后从PMD （这两个静态分析工具）开始。 我使用过FindBugs这个工具，它不会检查源代码，而是检查字节码本身，但在我看来只是很少使用，它报告了太多误报。

最后，我找到了SonarQube （当时称为Sonar）。 我没有立即爱上它，花了几个月的时间才摆脱了我以前的Checkstyle和PMD伙伴。 但是，我一开始就希望将其放置在我从事的每个项目以及其他项目中。 当它添加时间表以查看有关违规和其他指标的趋势时，我知道这是可以使用的质量工具。

现在终于尘埃落定了，我看不到很多组织都没有使用质量工具，那很好。 我没有想象过不与任何人共事：无论是作为开发人员还是团队负责人，无论是使用Sonar还是使用更简单的工具，它们的附加值都太大了，无法忽略。

另一方面，我对上升的趋势非常警惕：似乎一旦Sonar到位，开发人员和管理人员都将其报告视为上帝之道。 我可以从管理人员那里得到期望，但是我绝对不希望我的开发人员将自己的头脑放在一边，并将其职责委托给一种工具，无论使用哪种工具。 当将那些规则中的度量标准用作构建破坏者时，情况甚至会变得更糟：当构建失败是因为您的项目无法实现某些预定义的度量标准时。

当然，有一些方法可以减轻该问题：

• 仅使用声纳规则的子集。 例如，如果该类直接或可传递地实现Serializable，则检查私有静态最终serialVersionUID属性的违规行为完全无效。
• 使用NO-SONAR注释
• 配置每个项目。 例如，Vaadin项目应该将图形类从单元测试范围中排除，因为它们可能没有行为，因此也没有关联的测试（您是否对JSP进行单元测试？）。

恐怕这些只是绕过极限的方法。 每个工具都有一个严格的限制：它无法区分上下文，并且无论使用什么规则都一样。 作为附带说明，请注意大公司也是如此...最有趣的部分是，软件工程师通常是度量驱动的最积极的反对者-然后他们将SonarQube放在位以断言代码质量，他们在将结果进行情境化时比较固执。

高质量工具是使代码库更易于维护的重要资产，但是愚蠢地应用一个规则，因为该工具这么说-甚至更糟的是，用// NOSONAR注释代替代码库是一个严重的错误。 我赞成使用工具，而不是统治我的工具。 明白我的意思了吗？

翻译自: https://blog.frankel.ch/quality-tools-humble-servants-or-tyrans/

暴君专栏和谐按钮