SonarQube通常称为Sonar，是一种用于衡量代码质量的免费工具。它很快成为了软件工艺领域的宠儿。然而，我们看到了关于使用这个工具的一些常见偏差。尽管这个工具非常出色，但它也可能导致糟糕的实践。
请放心，这篇文章不是在抨击Sonar（SonarQube）；这个工具非常出色，它的受欢迎程度是完全应得的。如果您不熟悉它，SonarQube提供了仪表板，用于跟踪正在开发中的产品的源代码质量。用户只需点击几下，就可以获得更多有关如何改进的详细信息。这对于在整个产品开发过程中保持技术卓越非常理想。
Sonar（SonarQube） – 偏差
然而，我看到了很多关于这个工具使用的偏差…或者更准确地说，强制使用这个工具的偏差。
在一些组织中，这个工具实际上是由”工匠”团队强制使用的…但更糟糕的是，强制使用了所有的跟踪指标…尽管这些软件开发团队应该具有敏捷思维，但它们却陷入了ITIL的思维中。
但是，为什么要强制使用它？
根本原因最终与强制Scrum团队”精确”跟踪其速度的原因非常相似。
公司将使用这些指标来：
- 监测团队的技术质量
- 在团队之间进行比较
- 审查某些供应商的状况
- 提醒团队提供质量的义务
- …
总之，不幸的是，Sonar（SonarQube）经常被用于非常糟糕的原因。团队失去了他们的自主权，供应商的存在（虽然他们没有承认）受到了条件的限制，而聪明的人会利用中等代码获得好的结果…因为是的，任何系统都可以被操纵。
当我看到一些公司要求团队接受软件工艺的审计时…他们简直忘了敏捷本身…而且在我看来，我们甚至不能称之为”软件工艺”！
因此，请注意，这并不是所有公司的情况！
那么，如何使用Sonar（SonarQube）？
SonarQube应该为每个认为它可以帮助他们提高工作质量的团队提供的工具。我们不强加它，我们提供解决方案。
认为强制使用工具将能够强制提供质量是错误的！这些质量指标更有可能掩盖可怕的现实。
另一方面，想要使用Sonar（SonarQube）的团队有三倍多的机会编写真正干净的代码。为什么呢？因为他们受到了选择跟踪工作的动力。
软件开发者特别应该为那些希望得到帮助以不断改进的团队提供帮助。这正是技术教练非常有效的领域。
对团队进行强制性要求只会是画蛇添足…而由此产生的指标将在掩盖着更为严重的现实的数字中坚定不移。我们谈论的是”西瓜指标”！
实际上，Sonar（SonarQube）是一款出色的工具，但如果强制使用，它可能成为一种祸害。让我们保持敏捷，真正利用这个工具可以提供的好处！
Be the first to comment