第一次使用SonarQube，我从中吸取到了什么经验和教训？
在这篇文章中，我将分享我是如何知道SonarQube，以及作为团队领导来使用它的故事。我将让大家了解它是如何帮助我们改进代码，并帮助我培养一个拥有清洁代码的初级开发人员团队。我将分享我们在学习如何使用这个工具的过程中所犯的错误，为跟我们处于同样境况的人提供参考建议。
在这篇文章中，我将分享我是如何知道SonarQube，以及作为团队领导来使用它的故事。我将让大家了解它是如何帮助我们改进代码，并帮助我培养一个拥有清洁代码的初级开发人员团队。我将分享我们在学习如何使用这个工具的过程中所犯的错误，为跟我们处于同样境况的人提供参考建议。
开发应用程序可能会是一项复杂的任务
我们都知道，作为一名开发人员，成长是一个永无止境的旅程。我们必须不断学习新事物。就我个人而言，我是非常喜欢学习的，但有时我也会不知所措。回顾我的职业生涯之初，我意识到有多少东西等着我学习：现代JavaScript，ECMAScript，React，异步编程，CSS，Sass，flexbox，grids……这样的例子不胜枚举。随着经验的积累，我开始深入研究函数式编程、JavaScript中的CSS、高阶组件、性能分析等等。
最令我满意的作为开发人员的一点，就是能够一边学习各种技术，一边构建很酷的用户体验！这一直激励我走得更远，不断深耕，并最终帮助我了解前端软件的真正工作原理。
虽然学习的过程很有价值的，但掌握开发应用程序所需的所有语言和技术是很困难的。就我个人而言，我总觉得我缺少一个工具来帮助我将学习提升到一个新的水平——一个可以衡量我的代码质量并指出潜在的错误、不良模式和漏洞的工具。但我很幸运。我身边有一群才华横溢的开发人员，他们能够在代码审查期间帮助我发现代码中的缺陷。他们帮助我了解如何修复代码，以及作为一名开发人员应该如何提升自我。
我是如何知道SonarQube的
两年前，我成为一名前端工程经理，负责一个由六名前端开发人员组成的团队。我很快意识到，团队中的每个人都必须经历与我相同的学习历程，这让我深刻体会到制作一个好的Web应用程序需要多么严格的要求。不仅需要正确使用技术和工具，而且应用程序必须始终保持可维护性。如果考虑到每个人理解代码都是根据自己的经验来的，这就变得更加困难了。
为了达到这种严格程度，我们进行了代码审查、团队之间的知识共享同步，以及一个技术领导“委员会”来定义最佳实践并确保团队保持一致。但就算采取了以上所有措施，我们的应用程序质量仍然存在很大差距。更困难的是，我们的开发人员分布在不同的团队和城市。不过幸运的是，我们负责安全性、指标、工具和CI/CD设置的基础团队向我们推荐了SonarQube。
在安全团队完成了配置后，我们添加了一个sonar.properties文件来自动启动实例并将分析包含在发布过程中。那时，我们没有谈论产品将如何使用，它将如何工作，或者它背后的哲学是什么。但是，在将SonarQube添加到开发工作流程中后，我们很快意识到它在我们流程中充当的不仅仅是安全门限。
与SonarQube的第一步
使用SonarQube的最初几天充满了很多情绪。有些开发人员感到惊慌失措。他们有部分人反对该工具，其他人认为有些规则是不正确的，他们比工具更清楚。但在这个不确定的时期，团队聚在一起讨论不同规则的利弊。我们发现了为什么避免幻数（magic number，用来标记文件或者协议的格式）很重要，限制函数的认知复杂性，复杂性的正确极限是什么等等。我们还讨论了前端特定的需求：我们真的应该把路由路径设置为常量吗？应该避免硬编码值吗？但这样做适用于编码风格吗？
在团队内部进行了数天的对话后，我们决定建立自己的质量档案，这对我们来说很有意义。这样，我们可以将最近的所有讨论整合到一个我们都可以共享和使用的团队质量配置文件中。我们都认为Sonar的分析提供了丰富的信息，能够帮助我们创建一个流程，用来解决它检测到的问题。
该配置文件使团队对使用Sonar更有信心了。随着代码库对我们来说越来越清晰透明，我们发现了许多在拉取请求审查期间可能会遗漏的东西。此外，我们还讨论了每个问题背后的编码规则。这让初学者能够更快地学习，因为在质疑是否应该解决这个问题前，他们首先必须理解规则存在的原因以及它试图阻止什么。
SonarQube在我们的团队中迅速改进了什么
我很快就明白了开发人员对自己编写的代码质量有多么关心。事实上，我的团队中没有一个开发人员会忽视分析结果。即使在因为结果不够好而感到沮丧时，开发人员也会立即采取行动来改善他们的拉取请求。我相信每个开发人员都希望交付高质量的代码，只需要给予正确的工具和适当的讨论空间。
有了SonarQube，我们就有了评估代码质量所需的所有指标。我们知道哪些部分的代码是清洁的，哪些部分则需要改进。该工具帮助我们与项目经理一起确定工作的优先级。他们可以访问结果，并能够了解他们的产品是否存在风险。
我们还开始使用代码异味页面为新加入者创建入门工单（甚至添加到更小的Sprint中），这非常受欢迎。它让新加入的人能够从非常精确且易于测量的东西开始。
有了SonarQube的使用指标，我能够与内部技术领导委员会分享我们的成果，并了解其他团队如何使用它。我们以此为契机，在团队之间共享了一组最佳实践。
在使用SonarQube时，我们犯了哪些错误
在开始清洁代码之旅的初期，我们决定Sonar只用于提供信息。这是一个巨大的错误！我们安装了SonarQube，却没有对它的用途有足够的了解。
我多希望我以前知道“边写边清理”方法！直到我加入Sonar时，我才了解并发现它有多强大。显然，当您有成百上千个错误、安全漏洞和代码异味时，尝试全部修复它们简直是挑战不可能。这就是“边写边清理”的作用所在！
与其投入大量时间和精力来修复旧代码，不如专注于写清洁的新代码。这样，您就不会向代码库添加更多问题。
质量门限可以防止您合并不清洁的代码，帮助您确保不会向代码库添加任何关键问题。同时，当您在编写新代码时，不可避免地会接触到旧代码。很简单，因为在实现新功能的过程中，您要么删除一些代码(用新的代码替换它)，要么修改它以适应新功能的需要。平均而言，您每年会重写20%的应用程序代码。有了良好的设置和对工具的理解，提高应用程序的代码质量就不再是一件苦差事。
请相信SonarQube！
在学习如何使用SonarQube的过程中，我们犯了很多错误。我们是一个由初级开发人员组成的团队（我是一名初级工程经理），没有使用清洁代码解决方案的经验。引入SonarQube对我们来说是一个建立强大技术基础、进行许多有趣讨论的机会。它为团队带来了新的指导方针和指标，帮助我们在清洁代码策略上与项目相关人员保持一致。通过使用一组对我们有意义的规则来定义和执行质量配置文件，我们提高了代码的整体质量和一致性。在个人层面上，SonarQube对我来说也是一个机会，可以把更多的时间和精力花在团队的动态和氛围上，而不是在技术方面。
在经过了多次尝试、讨论和错误后，我们才弄清楚如何使用SonarQube。现在我在Sonar工作，我认识到质量门限和边写边清理方法可以帮助我们的业务更进一步。但是，没有人能在一帆风顺中学习。因此，以下是我对准备开始使用SonarQube的开发人员或开发团队的建议：
不要将SonarQube看作代码的又一个统计数据，而是采用清洁代码方法来帮助团队获得最佳结果。
利用质量门限来确保新代码的清洁，并使开发人员对其编写的代码质量负责。
讨论并定义一个有意义的质量概要文件，使用对您的团队有意义的正确规则集。SonarWay是最好的首选开始方式。
最后，通过与所有相关人员共享指标，让每个人从一开始就参与到清洁代码的策略中来。
文章来源：https://www.sonarsource.com/blog/developing-an-application-can-be-a-complicated-task/
想要了解清洁代码或体验SonarQube，请联系SonarQube中国官方授权合作伙伴——创实 ，我们提供SonarQube产品的咨询、销售、 实施、培训及技术支持服务。