在当今不断变化的开发环境下，保持较高的代码质量和较好的代码可读性对于项目的成功开发是极为重要的，尤其当多个团队在同一套代码上进行开发时，代码经常会被改变。这样的开发环境要求开发人员遵守一定的代码风格，使项目中的每位成员都能较好地理解项目中的代码。
对Infobip来说，我们发布的产品必须是高质量的。Infobip的每一款产品的核心都是其源代码，所以代码的质量就成为决定整个产品质量的重要因素。
为了控制代码的质量，我们选择在开发过程中实施代码评审。然而实施几次后，我们发现代码评审过程占据了大量的时间，使我们没有时间去做其他重要的任务。代码评审不仅包括创造性的评审过程，还包括使用常规规则对重复错误进行检查等。整个代码评审过程变成了一个新的问题，因此一个合理的解决方案就是把代码评审的工作部分自动化。
在我们的开发中心，我们正在试图尽可能地将更多的手工操作自动化，从而让我们能够集中精力去做其他创造性的工作，为我们的客户提供更好的服务。此刻我们的开发人员可以自动地部署服务，快速和容易地开发公共API，并用不同的编程语言生成客户端库。我们花费了很长的时间来找到一个完美的解决方案，帮助我们自动化地完成部分的代码评审工作。调研了各种不同的工具后，我们发现SonarQube符合我们所有的需求。
关于SONARQUBE
SonarQube是用来进行代码质量分析的开源平台。它属于静态代码分析工具，并带有Understand，semmle和其他工具。
SonarQube平台以源代码作为输入。源代码可以从IDE输入或者从SCM中提取。对于大多数流行的IDE，都有相应的SonarQube插件，使代码分析能够更加容易地在IDE中执行。SonarQube在源代码的基础上执行预定义的规则，检查规则是否被满足。分析的结果提供了大量有用的信息和代码改善意见。
我们选择SonarQube的原因在于它支持大量的以及可扩展的Java规则。现在已经有超过700个Java规则，并且规则的数量还在不断的增长。我们主要执行的是用Java编写的代码的检查工作，但SonarQube也可以容易地在用其他20种语言编写的代码上执行检查工作。
同时，SonarQube是插件化的。如果你需要对使用某一特定语言编写的代码进行代码检查，你可以编写自己的插件或者规则来实现。你可以比较容易地利用XPath表达式或用Java编写一个新的插件来添加自己的规则。
SonarQube平台包含了四个组件：分析器，服务端，安装在服务端的插件以及数据库。
SonarQube结构图
分析器负责一行一行地执行代码分析。它能够提供技术债务，代码覆盖率，代码复杂度，检测出的问题等信息。检查出来的问题可以是bug，潜在的bug，或者是可能在将来导致错误的问题等。当分析完成后，结果可以通过由SonarQube服务端提供的网页进行浏览。SonarQube的web服务器简化了SonarQube实例的配置，插件的安装等过程，并提供一个直观的结果概览图。
结果概览
在代码检查中可以发现很多问题。不同的规则基于他们的严重程度可以放入以下5组中的任意一组： Blocker, Critical, Major, Minor 和 Info。一旦某条规则发现了bug或潜在的bug，这些bug就会被标记为Blocker或者Critical，一些小的问题例如“魔数不应该被使用”则会被标记为Minor 或Info。
下面是经常被违反的规则示例：
经常被违反的规则
SonarQube最棒的地方在于所有数据都使用开发者们熟悉的关系型数据库存储。我们选择了MySQL数据库存储数据，选择MySQL数据库的主要原因是：我们热衷于开源技术。你可以选择你熟悉的其他数据库，例如PostgreSQL，Oracle等数据库。
SonarQube 安装
SonarQube的架构允许我们将SonarQube服务器和数据库分离，甚至你可以在多台机器上进行数据库复制和服务器部署，以获得更好的性能和扩展性。
为了测试和体验SonarQube的多种功能，可以使用内嵌了数据库的web服务器来尝试分析一个或两个项目。如果一开始就能把工作环境正确地搭建起来，那么将数据库和SonarQube服务器从本地开发机器迁移到真正的服务器上将不会有任何问题。同时，我们可以借助Docker容器来实现工作环境的迁移，将我们所需要的一切打包起来（代码，运行库和系统库）并轻松地部署至任何机器上。你可以使用官方的SonarQube docker容器 ，不必花费时间来创造自己的docker容器。我们也可以将数据库配置为外部数据库，也能够很好地配合SonarQube的使用。
起初，我们使用一个专用的虚拟机来部署SonarQube。我们没有遇到任何问题直到项目个数超过了一定的数量并且开始每天都进行代码分析。我们注意到SonarQube的性能急剧下降，代码分析花费的时间越来越长。于是我们开始研究将SonarQube的组件安装在不同的机器上来改善性能。我们分离了数据库和SonarQube服务器，但将SonarQube的各组件部署在同一个网络中。同时我们使用docker容器部署SonarQube，当我们需要更好的性能时，就可以很容易地将其部署至其他机器上。
SonarQube 和持续集成
如前所述，我们关注自动化，并尽量减少在可以自动化的工作上所花费的时间，从而我们能有更多的时间做其他更具创造性的工作。同时，代码分析也非常适合持续集成。
我们正践行着持续集成和敏捷开发，因此从我们的角度来看，一项任务的解决过程通常如下所述：
名为Alisa的开发者给自己分配了一项任务并开始了工作。在解决任务的期间，Alisa在IDE中一次又一次地执行代码分析并查看分析结果，从而检查是否所有的代码质量要求被满足。她需要亲自进行与代码逻辑相关的代码审查工作。当Alisa确定她所编写的代码满足所有的要求时，就将新的代码提交到仓库中并请求Bob进行代码审查。新代码被提交到git仓库后，web钩子将触发Jenkins构建。构建过程将自动地执行，Alisa开发的具有新功能的组件在内部的maven仓库中可用，并且可以轻松部署到生产环境中。
Bob对Alisa编写的代码进行审查，执行代码分析来判断其代码质量是否合乎要求。得到代码分析结果后，Bob仅需要完成代码审查中最具创造性的部分——代码逻辑的审查。如果所有的审查都通过，Alisa的任务将被标注为完成，新的功能也可以投入到生产环境中使用。
SonarQube持续集成结构图
SonarQube的4.0版本增加了增量分析模式。这个模式可以被用来检查新的改变是否破坏了一些重要的代码规则，需要开发者来进行相应的代码审查工作。在4.0版本之前，即使开发者仅改变了两个或三个文件，仍然需要对整个工程进行代码分析。增量分析模式的使用将大大减少代码分析运行的时间。除了增量分析模式外，还有完整分析模式和预览分析模式。完整分析模式会对整个项目的代码进行一行一行的分析，并将分析结果发送给服务器，存储在数据库中。预览分析模式也会进行完整的分析，但并不将分析结果存储在数据库中。
目前，在夜间构建时，我们使用完整分析模式，将分析结果存储起来。每次提交后，我们仅使用预览分析模式进行代码分析。
SonarQube和持续集成的结合提供了一种每次提交代码后进行代码质量审查的方法。除此之外，我们还可以得到关于代码质量的历史数据，并观察到在整个项目期间代码的质量表现。
结束
SonarQube 的使用使代码质量控制变地更加容易，并且能够减少真实的和潜在的bug的数量。开发者们能够更加专注于逻辑本身，花费更多时间进行业务分析，并为具体的案例寻找最有效的解决方案。使用了SonarQube 进行代码检查之后，管理者们开始跟踪代码分析的结果，因为他们相信这些结果能够较好地反应项目的开发状况。
正如John F.Woods所说“Always code as if the guy who ends up maintaining your code is a violent psychopath who knows where you live.” 你还在等什么？开始进行代码分析吧！
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
