Análise de código fonte em Java com ferramentas livres

É... Você era feliz e não sabia! Aquela ferramenta maneira, que você adorava usar para analisar código fonte em Java, subiu no telhado! E agora? O que fazer? Calma, pois existem várias ferramentas disponíveis para você usar, todas REALMENTE livres.




Eu escrevi alguns livros sobre qualidade de software:

• "Guia de Campo do Bom Programador", editora Brasport;
• "Qualidade de Software na Prática", editora Ciência Moderna;

E, nestes livros, usei algumas ferramentas de análise de código. Uma delas, em especial, era a que eu mais gostava. O problema é que, de repente, os seus desenvolvedores começaram a mudar os rumos e o "roadmap" dela. 

Começaram a trocar componentes e regras populares, por implementações obscuras, mudaram critérios de métricas para "suavizar" o impacto, e criaram versão paga. Bem, não preciso dizer o quão furioso eu fiquei com isso, afinal, eu tenho uma responsabilidade por aquilo que escrevo, ao contrário desses caras... (veja o artigo: "NSOSS"). 

Porém, nem tudo está perdido! Há como fazer um excelente trabalho de análise de código fonte Java, usando ferramentas que são REALMENTE e EFETIVAMENTE livres, e é o que eu quero demonstrar com este artigo.

O que realmente precisamos?

Precisamos de ferramentas que nos permitam tirar conclusões sobre a qualidade de um software, sem necessariamente ter que "mergulhar" no código fonte. 

E também precisamos que essas ferramentas:

1. Sejam fáceis de usar;
2. Sejam precisas e apontem efetivamente os problemas;
3. Sejam fiéis às definições das métricas utilizadas;
4. Tenham um "roadmap" evolutivo confiável.

Um dos maiores problemas algumas ferramentas de análise de código,  é a "suavização" de métricas. Seus desenvolvedores, talvez preocupados com o sucesso comercial das ferramentas, começaram a implementar medidas para diminuir os "falsos positivos", ou seja, apontamento de problemas que, na verdade, seriam de baixa gravidade. 

E, para isto, começaram a alterar a implementação dos algoritmos, de modo a tornar as medições mais "palatáveis". Com isto, várias métricas importantes tiveram seu cálculo adulterado, passando a gerar resultados pouco confiáveis, por exemplo: Ca (Acoplamentos Aferentes), Ce (Acoplamentos Eferentes) e LCOM4 (Lack of Cohesion of Methods - Hitz & Montazeri), entre diversas outras.

Ora, você acha que um software deve ter o poder de decidir o que é ou não é "falso positivo"? É claro que não! Com isso, o que esses desenvolvedores conseguiram foi criar "falsos negativos", ou seja, os reais problemas passaram a ser "mascarados". 

Como eu trabalho com análise de código fonte, preciso de ferramentas estáveis, precisas e fiéis às definições das métricas. Preciso que sejam mau humoradas e que ajam sem piedade, apontando os problemas que realmente existam. Eu é que decido se eles são ou não relevantes. 

E já temos isso tudo!

Para começar, temos o Apache Maven, que é uma excelente base para rodar qualquer análise sobre código Java. E depois, temos ferramentas para cada aspecto de um projeto de software: 

• Arquitetura: JDepend;
• Projeto e implementação: jQana;
• Qualidade de codificação: PMD, Checkstyle e FindBugs;
• Cobertura de testes: Cobertura;

Todas essas também são implementadas como "plugins" Maven, e podem ser utilizadas facilmente, bastando configurar o arquivo "pom.xml" do seu projeto: 

...
<pluginRepositories>
   <pluginRepository>
      <id>jqana-mvn-repo</id>
      <url>https://raw.github.com/cleuton/jqana/mvn-repo/</url>
   </pluginRepository>
</pluginRepositories> 
<reporting>
   <plugins>
      <!-- jQana -->
      <plugin>
         <groupId>com.obomprogramador.tools</groupId>
         <artifactId>jqana-maven-plugin</artifactId>
         <version>0.0.3</version>              
      </plugin>       
      <!-- Cobertura -->
      <plugin>
         <groupId>org.codehaus.mojo</groupId>
         <artifactId>cobertura-maven-plugin</artifactId>
         <version>2.5.2</version>
      </plugin>
      <!-- JDepend -->
      <plugin>
         <groupId>org.codehaus.mojo</groupId>
         <artifactId>jdepend-maven-plugin</artifactId>
         <version>2.0-beta-2</version>
      </plugin>   
      <!-- Checkstyle -->
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-checkstyle-plugin</artifactId>
         <version>2.10</version>
      </plugin>
      <!-- PMD -->
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-pmd-plugin</artifactId>
         <version>3.0.1</version>
      </plugin>
      <!-- Findbugs --> 
      <plugin>
         <groupId>org.codehaus.mojo</groupId>
         <artifactId>findbugs-maven-plugin</artifactId>
         <version>2.5.2</version>
      </plugin>
   </plugins>
</reporting>

Depois, é só rodar "mvn clean package", para compilar seu projeto, e "mvn site" para gerar o maven site com todos esses relatórios.

Resultados

Temos relatórios que cobrem basidamente TODAS as métricas necessárias para cada aspecto do projeto, por exemplo:

Arquitetura - JDepend

Projeto e implementação - jQana

Cobertura de testes - Cobertura

E você pode configurar estes relatórios para serem gerados no seu sistema de Integração Contínua, fazendo "deploy" do Maven site criado para um servidor Web (eu envio ao Github), dando visibilidade aos relatórios para os seus usuários. Isto é transparência!

Para saber mais...

Em minha próxima palestra do CISL - Comitê de Implantação de Software Livre, vou mostrar um tutorial de análise de código usando APENAS ferramentas LIVRES. Você pode assistir ao vivo, via videostreaming, ou pode ver o vídeo gravado posteriormente. Veja AQUI as informações sobre esta palestra.