去SonarQube还是不去SonarQube？

最新推荐文章于 2024-07-29 02:13:15 发布

danpu0978

最新推荐文章于 2024-07-29 02:13:15 发布

阅读量221

点赞数

文章标签： java python linux 项目管理 web

这是团队负责人，软件主管，客户，开发人员，架构师，测试人员或开发团队中存在的任何角色的第一个问题。关于使用另一个“质量工具”，这不是另一个问题。您已经安装了很多。这不是一个简单的问题，以了解您对测试覆盖率的关心程度或查找哪些类问题最多。没有比赛，也没有奖品！这是您需要回答的唯一问题，以显示您有多在乎，您真正在乎多少代码的整体质量。如果您从未使用过SonarQube，甚至从未听说过它，那么您就有机会了解这个小巧（但功能强大）的软件如何改变了我们（作为开发人员）的生活并增强了我们的产品。

黑暗。这就是我描述SonarQube之前我们的开发生涯的方式。我们对代码没有任何见识。我们没有进行任何单元测试。我们不知道当前的设计是否允许我们快速添加新功能或进行重要更改，这使我们对任何重构尝试都感到担忧。编码规则；问题；这些到底是什么？重复的代码？上帝保佑副本–粘贴。可测试性，稳定性，可变性是我们需要在中文词典中查找其含义的术语。在开发生命周期的后期发现了错误，导致了一些红色警报情况，并且发布似乎是我们的支持和测试部门必须对付的中年龙，然后才能向客户展示。然后发生了某种奇迹。我不记得我是如何到达SonarQube的，但是现在我很确定，我需要阅读SonarQube的功能的那10分钟改变了我们的观念。

无需任何考虑，我就下载并安装了它。我兴奋不已，分析了自己喜欢的项目，几分钟后，我在我的第一个SonarQube仪表板前盯着屏幕看。我的第一感觉是非常失望：“我们的代码太烂了！”。很快，我意识到了这种未知工具的可能性，并激发了我的潜能。我立即向团队展示了它，并向他们简要解释了它们，不同的度量标准及其对代码质量的含义。一个新时代已经开始。今天，SonarQube跟踪我们所有的项目。每天早上，团队成员都会检查项目仪表板，尤其是上次分析的差异视图。我们为最重要的指标配置了阈值，因此只要新代码达到阈值，构建就会中断。我们像处理所有损坏的构建一样处理这些构建：修复它们的ASP并恢复所需的质量。在开始重构任务之前，我们总是向SonarQube咨询设计不良的迹象。从项目开始的第一天起，我们就一直致力于代码质量，SonarQube是我们曾经努力过的最好的盟友。我很高兴看到我的气泡（动态图表）改变颜色并走向完美。我喜欢看到我的项目Treeview从红色变为绿色。从一个角度来看，我可以找出哪些组件需要我们进一步关注。只需拿起红色的大个子，开始清理您的代码！

我们的新产品版本更加稳定。从龙变成蝴蝶。对我们团队的信任和信心大大增强。当我们添加新功能或修改现有功能时，我们不会感到恐惧。换句话说，这就是我们SonarQube的生活！有时，我想知道几年前我们的代码如何“呼吸”。 SonarQube给了我们缺少的氧气。我已经对我自己回答了这个问题。我选择了光明而不是黑暗。轮到你了！

参考： 到SonarQube还是不给SonarQube？从我们的JCG合作伙伴 Patroklos Papapetrou在Only Only软件问题博客上获得。