Development

Melhorando a qualidade do código com SonarQube

Desenvolvedor, confira como melhorar o processo de revisão da qualidade do código com SonarQube.

January 22 2016

Manter o nível de qualidade e legibilidade do código é fundamental quando se trata de realizar um desenvolvimento bem sucedido no atual e dinâmico mercado de desenvolvedores, no qual várias equipes trabalham no mesmo código e fazem mudanças constantemente. Tal ambiente exige que certas convenções de codificação sejam seguidas, para que o código possa ser compreendido por todos os envolvidos no processo.

Para nós da Infobip, é imperativo que os produtos que oferecemos atendam os mais altos padrões de qualidade. No centro de cada produto há um código fonte, que faz com que a qualidade do código seja o fator mais importante para determinar a qualidade geral do produto.

Para manter o controle de alta qualidade, decidimos implementar a revisão do código dentro do nosso processo de desenvolvimento. Contudo, as revisões passaram a tomar muito tempo, fazendo com que nos desviássemos de outras ações relevantes. Isso porque a revisão do código consiste, não somente no processo de revisão criativa, mas também na verificação de erros repetitivos, do uso das regras convencionais etc. O processo como um todo foi questionado, de modo que a solução lógica era automatizar parte dele.

Em nossos centros de desenvolvimento, estamos buscando automatizar o maior número possível de tarefas manuais, para que possamos focar em inovação e ser a melhor opção para os nossos clientes. Hoje, nossos desenvolvedores podem implantar serviços automaticamente, escrever facil e rapidamente APIs públicas e gerar bibliotecas para os clientes em diferentes linguagens de programação. Demorou até que encontrássemos a solução perfeita, que nos ajudasse a automatizar parcialmente a revisão de código. Após pesquisar várias ferramentas, percebemos que SonarQube atende todas as nossas necessidades.

Sobre SonarQube

SonarQube é uma plataforma de código fonte aberto para a análise da qualidade do código. Ela pertence às ferramentas de análise estática de código, assim como o Understand, semmle, entre outros.

A plataforma recebe o código fonte como base. Esse código pode ser enviado pelo IDE ou puxado pelo SCM. Existem pluggins da SonarQube para os mais populares IDEs, que facilitam ainda mais a execução da análise do código. Com base no código fonte inserido, a plataforma aplica as regras pré-definidas e verifica se elas estão sendo cumpridas. Ao final da análise, são fornecidas várias informações úteis e sugestões de melhoria.

Escolhemos a SonarQube, porque ela possui numerosas e extensas regras de Java. Atualmente, há mais de 700 regras de Java, e esse número está aumentando constantemente. Estamos realizando, principalmente, análises em códigos escritos em Java, mas a análise pode ser feita facilmente em códigos escritos em outras 20 linguagens de programação.

Além disso, a SonarQube permite vários plugins, assim, você pode escrever seus próprios plugins, caso necessite de suporte em uma linguagem específica ou queira escrever suas próprias regras. Se precisar adicionar suas próprias regras de código, é possível utilizando expressões XPath ou criando um novo plugin usando Java.

A plataforma SonarQube é composta por 4 componentes: analisadores, servidor, plugins instalados no servidor e base de dados.

arquitetura SonarQube

Os analisadores são responsáveis pela execução da análise do código linha por linha. Eles podem fornecer informações sobre dívida técnica, cobertura do código, complexidade do código, problemas detectados etc. Os problemas detectados no código podem ser bugs, bugs potenciais, tópicos que podem levar a erros no futuro etc. Quando a análise é concluída, os resultados podem ser visualizados em uma página hospedada no servidor web da SonarQube. O servidor web simplifica a configuração da instância da SonarQube, a instalação de plugin e oferece uma visão geral intuitiva dos resultados.

Enigneering

visão geral dos resuldados

Há diversos problemas que podem ser encontrados em um código. As regras são diferentes e podem ser colocadas em um dos 5 grupos, com base na sua gravidade: Bloqueador, Crítico, Principal, Pequeno e Info. Sendo assim, se houver um bug ou bug potencial, ele será caracterizado como Bloqueador ou problema Crítico, e, alguns, como problemas pequenos. Um exemplo são os “números mágicos que não devem ser usados”, que são classificados como Pequenos ou Info de gravidade.

Aqui está um exemplo das regras mais violadas:

Engineering

regras mais violadas

A melhor coisa da SonarQube é que todos os dados são armazenados em um banco de dados relacionado, com o qual todos os desenvolvedores estão familiarizados. O banco de dados que escolhemos foi o MySQL. Isso se deu, principalmente, porque somos ávidos defensores de tecnologias com o código fonte aberto. Se preferir ou tiver mais experiência trabalhando com outros bancos de dados, você pode optar por eles. Alguns dos suportados são: PostgreSQL, Oracle etc.

Configuração SonarQube

A arquitetura da SonarQube permite separar o servidor do banco de dados e, até mesmo, fazer repetições de banco de dados e implantar o servidor em várias máquinas para alcançar um melhor desempenho e escalabilidade.

Para testar e experimentar as várias funcionalidades da SonarQube, você pode usar um servidor web com um banco de dados integrado, e analisar um ou dois projetos. Se o ambiente estiver configurado corretamente desde o começo, não haverá problemas na migração do banco de dados e do servidor da SonaQube de uma máquina de desenvolvimento local para outro servidor. O Docker, com os seus recipientes, podem ajudar nisso, já que é possível embrulhar tudo o que precisa (código, tempo de execução, bibliotecas do sistema) e implantar facilmente em qualquer máquina. Também existe o recipiente docker oficial da SonarQube com uma versão H2 integrada, para que você não perca tempo criando o seu próprio. O banco de dados externo também pode ser configurado, o que é necessário para qualquer trabalho mais sério com a SonarQube.

Começamos com uma máquina virtual dedicada e não tivemos problemas até que passamos um certo número de projetos e iniciamos a análise o código diariamente. Assim, notamos uma drástica queda de desempenho e aumento no tempo de duração das análises. Foi quando passamos a separar diferentes camadas SQ (arquitetura) em máquinas distintas.

No início, separamos o banco de dados e o servidor da Sonar. Aceitamos as recomendações da SonarQube de manter a mesma rede. Para a implantação da SonarQube usamos um recipiente docker para facilitar a instalação em outra máquina, caso seja preciso melhorar os níveis de desempenho.

SonarQube e integração contínua

Como falamos anteriormente, nós automatizamos e buscamos gastar menos tempo com coisas que podem ser automatizadas, criando assim mais tempo para a parte criativa do trabalho. A análise de código também se encaixa perfeitamente dentro da integração contínua.

Por isso, praticamos e pregamos a Integração Contínua e o desenvolvimento ágil. Sendo assim, veja como realizamos o processo de solucionar uma tarefa:

Tudo começa com a desenvolvedora (vamos chamá-la de Alisa), atribuindo a tarefa para si e iniciando o desenvolvimento. Durante a resolução da tarefa, Alisa executa a análise do código em IDE várias vezes e recebe o resultado. Ela verifica se todos os requisitos de qualidade do código estão satisfatórios. Mas quando se trata de lógica, ela mesma faz a verificação. Então, logo que Alisa tem certeza de que o código escrito preenche todos os requisitos, ela o envia para o repositório e pede para Bob revisá-lo. Depois de enviar as mudanças para o repositório git, a web solta um gatilho para o Jenkins. O software é executado automaticamnete e a peça com os novos recursos é disponibilizada em um repositório maven interno, podendo ser facilmente colocada em produção.

Bob faz a revisão do código que Alisa escreveu e roda a análise para determinar se a qualidade do código está no nível desejado. Após a interpretação dos resultados, Bob só precisa realizar a parte criativa da revisão do código – revisar a lógica. Se tudo estiver ok, a tarefa foi concluída e a produção do novo recurso finalizada.Engineering

gerenciamento do código fonte com o servidor CI e SonarQube

Na versão 4.0 é introduzido o modo de análise incremental. Este modo pode ser usado para verificar se as novas alterações quebrarão alguma importante regra de código e deve ser executado pelo desenvolvedor responsável pelas mudanças. Antes da versão 4.0, um desenvolvedor precisaria começar a análise em todo o projeto, mesmo tendo alterado somente dois ou três arquivos. Com este novo recurso, o tempo necessário para a análise é bem menor. Junto ao novo modo incremental, também há a análise do projeto como um todo – análise linha por linha com envio dos resultados para o servidor e armazenamento no banco de dados, e o modo de pré-visualização que faz a análise completa, mas sem o armazenamento das informações no banco de dados.

Atualmente, estamos usando o modo de análise completa do projeto, com armazenamento dos resultados – para os desenvolvimentos feitos à noite, e o modo de pré-visualização – após cada envio.

Isso nos permite rastrear o controle de qualidade do código a cada envio. Além disso, temos o histórico sobre a qualidade do código, para observarmos o comportamento dessa qualidade durante o projeto.

Conclusão

O uso da SonarQube facilita o controle de qualidade do código e diminui o número de bugs reais e potenciais. Os desenvolvedores agora estão mais focados na lógica e podem dedicar seu tempo para os requisitos de análise do negócio e para encontrar a solução ideal para casos concretos. Também, após sua implementação, os gerentes começaram a monitorar métricas, pois, com base nos seus resultados, é possível ter uma visão melhor do trabalho de desenvolvimento.

Citando John F. Woods:

Sempre crie um código pensando que o último cara que irá mantê-lo é um psicopata violento que sabe onde você mora.”

O que você está esperando? Hoje é um ótimo dia para analisar um código.

Nevena Menkovic, Software Engineer