Introdução ao SonarQube

Olá Pessoal, tudo bom?

O artigo de hoje irá apresentar um pouco sobre o SonarQube, ferramenta de qualidade de código de software para diversas linguagens de programação. Veja na continuação…

SonarQube

É uma ferramenta de análise de código que auxilia o gerenciamento da qualidade interna do software. Isso é importantíssimo se queremos que o software possua uma boa qualidade e que possamos melhorá-la. Assim o SonarQube mais conhecido como Sonar é uma plataforma de código aberto desenvolvida pela SonarSource para inspeção contínua da qualidade de código com as seguintes características:

• Multilinguagem: ABAP, C/C++, C#, COBOL, Flex, Go, Java, JavaScript, Objective-C, PL/SQL, PL/I, PHP, Python, RPG, Swift, T-SQL, TypeScript, VB .NET, VB6, Web, XML
• Integração Devops: Build: Maven, Ant, Gradle, MSBuild, Makefiles
• Integração Contínua: Jenkins, VSTS, TFS, Travis-CI
• Qualidade Centralizada: visão integrada “cross-projects”

 

Métricas

O SonarQube oferece uma série de métricas sobre a qualidade do código, entre elas estão:

• Complexidade (ciclomática e cognitiva)
• Código duplicado
• Quantidade de Problemas
• Tamanho (quantidade de linhas de código, número de classes, etc…)
• Cobertura de testes
• Índice de Manutenibilidade, Confiabilidade e Segurança

 

Regras

O SonarQube se baseia em regras pré-definidas para analisar o código. Uma regra é uma boa prática e cada linguagem possui um grupo de regras relacionadas. Toda a regra possui uma descrição, normalmente, com exemplo de código e links para descrições mais detalhadas, o que ajuda o desenvolvedor a entender e resolver o problema relacionado, como mostra a Figura 01.

 

Issues (Problemas)

Toda vez que um código quebra uma regra, uma Issue é gerada. As Issues estão divididas nas seguintes categorias:

 

• Code Smells: problemas relacionados a manutenibilidade do código. Deixar isso como está significa que, na melhor das hipóteses, os desenvolvedores terão mais dificuldade do que deveriam para fazer alterações no código. Na pior das hipóteses, eles ficarão tão confusos com o estado do código que introduzirão mais erros à medida que fizerem alterações.
• Bugs: itens que representam erros no código que, se ainda não aconteceram em produção, provavelmente acontecerão, e no pior momento possível. Isso precisa ser corrigido.
• Vulnerabilities (Vulnerabilidades): são fraquezas ou brechas de segurança na aplicação.

 

Além de categorias, as Issues também são classificadas por severidade, conforme abaixo:

 

Existem sete coisas diferentes que você pode fazer com uma Issue (além de corrigi-la!)

 

• Confirm (Confirmar): ao confirmar um problema, você está basicamente dizendo “Sim, isso é um problema”. Ao fazê-lo, ele sai do status “Aberto” para “Confirmado”.
• False Positive (Falso Positivo): olhando para a questão em contexto, você percebe que, por qualquer motivo, esse problema não é realmente um problema. Então você marca como falso positivo e segue em frente.
• Won’t Fix (Não será corrigido): olhando para o problema no contexto, você percebe que, embora seja um problema válido, não é um problema que realmente precisa ser corrigido. Em outras palavras, representa dívida técnica aceita.
• Change Severity (Mudar severidade): este é o meio termo entre as duas opções anteriores. Sim, é um problema, mas não é um problema tão ruim quanto a gravidade padrão da regra diz. Ou talvez seja muito pior. De qualquer forma, você ajusta a gravidade do problema para adequá-lo ao que você acha correto.
• Resolve (Resolver): se você acha que resolveu um problema em aberto, pode escolher esta opção. Se você está certo, a próxima análise irá movê-lo para o status fechado. Se você estiver errado, o status será reaberto.
• Assign (Atribuir): depois que os problemas passarem pela revisão técnica, é hora de decidir quem vai lidar com eles. Por padrão, eles são atribuídos ao último committer no momento em que o problema é levantado, mas você pode reatribuí-lo a si mesmo ou a outra pessoa. O responsável receberá uma notificação por e-mail da tarefa se ele se inscreveu para notificações, e a atribuição será exibida em todos os lugares em que o problema for exibido.
• Comment (Registrar comentário): a qualquer momento durante o ciclo de vida de um problema, você pode registrar um comentário sobre ele. Comentários são exibidos nos detalhes do problema. Você pode editar ou excluir os comentários que você fez.

 

Quality Profile (Perfil de Qualidade)

As Issues são geradas a partir das regras pré-definidas, que, por sua vez, estão relacionadas a um Quality Profile (Perfil de Qualidade). Cada linguagem possui um perfil de qualidade associado. Além disso, o SonarQube permite extensão de perfis através de herança.

 

Quality Gate (Meta de Qualidade)

Um Quality Gate (Meta de Qualidade) é uma meta que deve ser atingida antes que uma build possa ser liberada. Por exemplo:

Posso liberar uma build hoje? Sim, desde que:

• Os índices de Confiabilidade, Segurança e Manutenibilidade do novo código sejam = A
• 90% dos testes unitário passarem com sucesso

finally {

Duvidas ou sugestões? Deixe seu feedback! Isso ajuda a saber a sua opinião sobre os artigos e melhorá-los para o futuro! Isso é muito importante!

Até a próxima!