Análise de Código utilizando SonarQube

No meu último post falei sobre métricas de código e os benefícios que eles podem trazer para a boa saúde do código. Hoje irei apresentar uma ótima ferramenta para gerar automaticamente estas métricas, SonarQube.

SonarQube é um software open-source que se propõe a ser a central de qualidade do seu código-fonte, lhe possibilitando o controle sobre um grande número de métricas de software, e ainda apontando uma série de possíveis bugs. Tudo isso é gerado através de uma análise completa do código, e após isso os resultados obtidos são mostrados através de uma interface web, em forma de dashboards, e gráficos. Um exemplo do resultado disto pode ser visualizado nesta página.

Iniciando o SonarQube

Vejamos então como configurar o SonarQube. Para este exemplo irei utilizar um projeto Java do jogo FizzBuzz. Além de Java, mais de 25 linguagens são suportadas como C# e Python por exemplo. Uma lista completa pode ser conferida aqui.

Baixe o SonarQube 3.6.3. Descompacte o arquivo em uma pasta de sua escolha. Abra a pasta “sonar-3.6/bin” e entre na versão relativa ao seu sistema operacional. Execute o arquivo StartSonar.bat (no caso do Windows). Um console irá aparecer e executar o serviço do Sonar. Para verificar se tudo ocorreu corretamente acesse o seguinte endereço em seu navegador: http://localhost:9000/. A tela abaixo deve aparecer.

exemplo

Tela de apresentação do SonarQube

Configurando o projeto

O próximo passo será criar o arquivo de configuração. Crie um arquivo com o nome “sonar-project.properties” na raiz de seu projeto. Abaixo segue o arquivo com a configuração para o projeto exemplo, copie para o seu arquivo e faça as adaptações necessárias para o seu projeto.

# metadados requeridos

sonar.projectKey=FizzBuzzSonarExample

sonar.projectName=FizzBuzzSonarExample

sonar.projectVersion=0.1

# caminhos para os códigos fontes

# caminhos podem ser separados por vírgula

sonar.sources=src/main/java

sonar.tests=src/main/test

# A linguagem do projeto

sonar.language=java

# Formato

sonar.sourceEncoding=UTF-8

Analisando o código

Para fazer a análise do código iremos utilizar o SonarQube Runner. Baixe o arquivo SonarRunner 2.2.2, e extraia o conteúdo em uma pasta de sua escolha. Agora é necessário adicionar o caminho onde se encontra o arquivo “sonar-runner.bat” às variáveis de ambiente (no caso do Windows). Clique com o botão direito em Computador e escolha propriedades. Vá em Configurações avançadas do sistema e entre em variáveis de ambiente. Edite a variável Path, adicionando no final o caminho para o SonarQube Runner, que irá ser algo como: “suaPasta\sonar-runner-2.2.2\bin”

variaveis

Adicionando o SonarQube Runner às variáveis de ambiente

Feita a configuração, é hora de análisar o projeto. Se certifique que o SonarQube foi iniciado e que seu projeto tenha o arquivo “sonar-project.properties”. Através do Prompt de Comando, navegue até a pasta raiz de seu projeto e digite o comando: “sonar-runner”. Se tudo ocorrer bem a análise deve iniciar e o resto do trabalho é feito automaticamente. O tempo de duração irá variar de acordo com o tamanho de seu código, e no final uma mensagem de sucesso é exibida.

prompt

Mensagem de sucesso na execução do Sonar Runner

Agora você pode acessar novamente o endereço http://localhost:9000/ para conferir o resultado. Os dashboards com as métricas padrões serão exibidos. Você pode configurar os dashboards, efetuando login com usuário: admin, e senha: admin. 

Por fim acesse a documentação oficial para conhecer as diversas opções de métricas disponíveis, e escolha as que atenderem o seu projeto.

Anúncios

Clean code good! Spaghetti code bad!

Desculpem pelo título em inglês, era para poder fazer a piada. O ponto é que ler um código espaguete é diferente de comer espaguete. O código neste “formato” provoca dores de cabeça e muitas vezes gera sentimentos como ódio, fúria, principalmente se você é chamado para corrigir algo em um código assim perto das 18h da sexta-feira.

O ideal é poder iniciar novos sistemas com boas práticas, de padrões de projetos e facilidade de leitura. Mas nem sempre é assim. E aí vem a importância do estudo contínuo de orientação a objetos, padrões de projetos, e tópicos de engenharia de software em geral.

excelencia-tecnica.032

Uma das referências neste aspecto é Bob Martin, o Uncle Bob.

Usei o Uncle Bob como motivação em alguns time que trabalhei, usando a regra da banda verde.  Selecionava pessoas que acreditava que tinham potencial de disseminar a cultura de TDD e Clean Code pela equipe, e doava uma banda verde para que aquele desenvolvedor sempre que fosse tocar no código se lembrasse de manter o código limpo e desenvolver como um desenvolvedor profissional.

Praticar código limpo. Se eu posso dar um conselho para você, esse é o meu conselho. E dentro da prática, está em transformar código. E transformar com paciência. Baby steps. Saber que débito técnico é uma realidade em qualquer código de produção. Mesmo times ágeis focados em refactoring, testes e qualidade no código sempre, encontrarão oportunidades de melhoria, para ganhar mais desempenho e estabilidade em algum pedaço de código fonte.

Pensando nisto trouxe um dojo diferente para a equipe. Coloquei um código Java ruim, com vários pequenos problemas que passam desapercebidos pelos desenvolvedores muitas vezes, para que durante o espaço do dojo o time fosse trabalhando criando testes básicos para garantir o comportamento do fonte e a partir daí focassem na refatoração da estrutura. Dá para ver o resultado depois de 40mins programando em um repositório do github. Lá tem o código original para quem quiser brincar.

Os Coding Dojos são excelentes oportunidades para a prática do código limpo. Seja de um problema do zero como de um problema “pronto” para ser transformado, como é o caso deste “bad code dojo”. Estudar ferramentas de apoio no processo do TDD, como ferramentas de auditoria de código fonte e cobertura de testes, também são ótimas possibilidades. No meu post sobre TDD tem algumas dicas.

E essa prática dever ser igual a do seu esporte favorito. Deve fazer parte da sua rotina praticar código e resolver problemas. Escolha um kata, e pratique código limpo! Comecei o post em inglês e vou terminar com uma tagline para vocês sobre qualidade de código e testes. Só quem faz teste automatizado vai entender:

Keep the bar green to keep the code clean!

Métricas de Software X Saúde do Código

Você já deve ter ouvido falar sobre a importância da qualidade de um produto ou serviço certo?

Diversas áreas se preocupam com isso, da construção civil e seus prédios, à um médico ao realizar uma cirurgia. Mas e na área de desenvolvimento de software, quais ferramentas temos a disposição para garantir a qualidade e excelência de nosso produto, o software? Temos diversas respostas para estas pergunta: metodologias e processos, testes de aceitação, testes funcionais, testes de stress. Estas ferramentas tem por objetivo garantir a qualidade a nível de cliente, fazendo com que o produto atenda as demandas corretamente para as quais foi projetado.

Mas e para nós desenvolvedores, o que pode ser considerado como um software de qualidade? O estudo da engenharia de software nos remete a diversos problemas que o desenvolvedor deve procurar evitar para obter código fonte de qualidade. Duplicidade de código, métodos e classes com muitas responsabilidades, alta complexidade ciclomática, ausência de testes unitários, entre outros.

Partindo da premissa de que o desenvolvedor conhece as boas práticas de programação, controlar a propagação destes fatores indesejáveis, em um projeto pequeno pode ser fácil. Mas atualmente a realidade é outra, projetos tendem a serem escaláveis e crescerem ao longo do tempo. Além disso dificilmente o desenvolvedor irá trabalhar sozinho, o desenvolvimento distribuído já é realidade na maioria da empresas. Nesses casos é muito fácil a equipe perder o controle da dimensão do software e de seus problemas.

E é neste cenário que entram as métricas de software. Existem diversas métricas, cada uma medindo um aspecto do software. Abaixo seguem alguns exemplos:

Número de linhas de código (LOC, KLOC): Mostra a quantidade de linhas do código fonte. Deve-se ter cuidado com está métrica quando utilizada para fazer comparações. Um maior número de linhas de código não significa necessariamente que um software é maior que outro. Por exemplo diferentes linguagens de programação necessitam de número de instruções diferentes para executarem as mesmas coisas.

Complexidade Ciclomática (CC): Fornece uma medida sobre a complexidade do software. O cálculo de complexidade ciclomática leva em conta quantos desvios uma função possui. Cada comando if, switch, for, while, é considerado um desvio do fluxo principal do código. Toda função possui como valor padrão 1, já que pelo menos um caminho é possível para o código. Conforme são inseridos os desvios este número aumenta. Como dito por Robert C. Martin em seu livro Código Limpo, cada método deve ter uma única responsabilidade, portanto devemos sempre buscar manter este indicador baixo, garantindo a manutenibilidade de nosso código.

Falta de coesão em métodos (LCOM): Esta métrica mede o nível de coesão de uma classe através da verificação do número de acessos a atributos em comum pelos métodos. Se a classe possui um método A que acessa os atributos B e C, e um método D que acessa os atributos E e F, a métrica considera que essa classe tem duas responsabilidades. Quanto maior o LCOM, mais responsabilidades a classe possui, tornando-a pouco coesa. Assim como outras métricas, este valor não pode ser considerado totalmente verdadeiro. Em algumas ocasiões, em virtude das regras de negócio, dois conceitos que parecem ser responsabilidades distintas, na verdade fazem parte do mesmo escopo. Portanto sempre deve-se analisar minuciosamente o código com LCOM alto, para tomar as ações corretas.

Estas métricas são apenas um exemplo, existem outras diversas. Mas a pergunta que fica é como calcular de forma efetiva estas métricas? Existem diversas ferramentas utilizadas para medição de software, algumas servem para métricas específicas, mas existem soluções como Sonarqube que oferecem um pacote de métricas que podem ser utilizadas pelos desenvolvedores para monitorar o estado do código de maneira simples e rápida. Algumas destas ferramentas também auxiliam a comparação do código em um período de tempo, assim possibilitando a criação de gráficos que mostrem a evolução de nosso software.

Um bom exemplo disso seria um gráfico do tipo Cobertura de testes X Complexidade ciclomática. Quando evoluímos o software inserindo novas features, devemos ter o cuidado de não inserir complexidade desnecessária, visando a boa evolução do código. Abaixo segue um exemplo de como esse tipo de gráfico nos fornece um rápido feedback sobre o código:

Gráfico de complexidade do framework Struts

Este gráfico mostra claramente que o framework Struts inseriu alguma funcionalidade que aumentou a complexidade do código drasticamente, e que a cobertura de código caiu quase na mesma proporção.

Como vimos o monitoramento das métricas de software pode ser essencial para a manutenção da saúde de nosso código. Cabe a nós desenvolvedores, ou aos times que resolverem adotar esta prática, utilizarem com parcimônia. De nada adianta possuirmos um dashboard com diversas métricas se a maioria não faz sentido para o nosso caso. Também vale ressaltar que as medições devem servir como base para planos de ação, caso contrário se tornam apenas números. Para começar, escolha de 3 a 5 métricas e ataque os pontos críticos, com o tempo você pode adotar outras, mas sempre visando a melhoria continua e consequentemente a qualidade de seu código.