Estamos trabalhando em um projeto da web do zero e examinando as seguintes ferramentas de análise de código estático.
O projeto é construído em Maven. Em vez de usar várias ferramentas para esse propósito, estava procurando uma única solução flexível e me deparei com o SonarQube.
É verdade que podemos alcançar os resultados de Checkstyle, PMD e Findbugs com SonarQube?
Respostas:
O Sonar executará CheckStyle, FindBugs e PMD, bem como alguns outros "plug-ins" como Cobertura (cobertura de código) por padrão para projetos Java. O principal valor agregado, porém, é que ele armazena o histórico em um banco de dados. Você pode então ver a tendência . Você está melhorando a base de código ou está fazendo o oposto? Apenas uma ferramenta com memória pode dizer isso.
Você deve executar o Sonar em seu sistema de CI para que mesmo coisas que demoram algum tempo para serem executadas (como CPD - detector de copiar e colar) possam ser executadas. E você terá sua história. Enquanto com um plugin do Eclipse, por exemplo, você detectará violações mais cedo - o que é ótimo - mas você ficará tentado a executá-lo com menos frequência se começar a demorar muito, ou executar menos "plug-ins de qualidade" (como pular CPD ou pulando a análise de cobertura de código). E você não terá história.
Além disso, o Sonar gera relatórios visuais , estilo "Dashboard". O que o torna muito fácil de entender. Com o Sonar no Jenkins, você poderá mostrar aos desenvolvedores e ao seu gerenciamento os efeitos do trabalho realizado na qualidade da base de código nas últimas semanas e meses.
O Sonar usa essas 3 ferramentas como plug-ins e agrega os dados de todas as três, dando valor de adição ao mostrar gráficos e outros recursos dessas ferramentas. Portanto, eles são complementares ao sonar.
Sim e não. Além das outras respostas.
SonarQube está atualmente em vias de descontinuar PMD, Checkstyle e Findbugs e usar sua própria tecnologia para analisar código Java (chamado SonarJava ). Eles fazem isso porque não querem perder tempo consertando, atualizando (ou esperando por isso) essas bibliotecas (por exemplo, para Java 8), que, por exemplo, usa bibliotecas desatualizadas.
Eles também têm um novo conjunto de plug-ins para seu IDE pessoal chamado SonarLint .
O sonar é ótimo, mas se você quiser usar as ferramentas mencionadas separadamente e ainda ter bons gráficos, pode usar o plug-in Analysis Collector como parte de seu build de CI do Jenkins. Uma pequena vantagem disso é que você pode verificar sua configuração PMD / Findbugs / Checkstyle em seu SCM e integrá-la à construção do Maven, em vez de depender de um servidor Sonar separado.
O Sonar é muito mais do que apenas essas ferramentas. O maior benefício é o gui, que permite configurar qualquer coisa facilmente. As estatísticas que oferece são muito detalhadas (linhas de código, etc.). E ainda oferece ótimo suporte para cobertura de teste, etc :)
Aqui você pode dar uma boa olhada: http://nemo.sonarsource.org/
Eu ainda usaria essas ferramentas além do sonar porque elas podem falhar na construção do maven quando alguém viola uma regra. Onde o sonar é mais retrospectivo.
... alguns anos depois: não, não é! SonarQube supõe ser capaz de cobrir todas as regras com seu próprio analisador, mas ainda existem regras de PMD ou CheckStyle não cobertas por SonarQube. Veja por exemplo: PMD ReturnFromFinallyBlock.
Bem, pelo menos desde SonarQube 6.3+, parece que Findbugs (no momento) não é mais suportado como plugin. Sonarsource está trabalhando na substituição das regras Findbugs por seu próprio plugin Java.
Eles ainda têm uma lista para o status de substituição de cada regra aqui: http://dist.sonarsource.com/reports/coverage/findbugs.html