Sonar 2.4: Regras de Restrições de Arquitetura e Suporte ao Maven 3

A última versão do Sonar, ferramenta open source de gerenciamento de qualidade de código, suporta restrições de arquitetura para projetos Java e painéis customizados. O time da SonarSource lançou no mês passado a versão 2.4 de seu produto. Neste lançamento, há quatro novas funcionalidades principais:

Regras de Arquitetura: Regras de restrições de arquitetura que permitem aos desenvolvedores definir o padrão para não permitir referências de classes em diferentes pacotes. Alguns exemplos de padrões incluem acesso a *.web, * from *.dao.* ou restrições a java.util.Vector, java.util.Hashtable ou java.util.Enumeration de qualquer classe. Um projeto está de acordo com o modelo arquitetural quando o código fonte adere às restrições de arquitetura. É necessária a análise do bytecode Java para esta regra.

Painéis Customizados: Os usuários do Sonar agora podem criar os seus painéis customizados (dashboards) para pessoas diferentes que estão relacionadas ao projeto, como gerentes, desenvolvedores, etc. O processo de customização do painel inclui selecionar layouts e adicionar e organizar widgets. Os administradores podem compartilhar painéis com todos os usuários e escolher qual painel será visualizado por padrão. Lançamentos futuros do Sonar incluirão novos widgets nos painéis, assim como regras de acesso aos usuários.

Centro de Atualizações: O novo Centro de Atualizações pode ser utilizado para instalar e atualizar plugins. Os usuários também podem obter informações de plugins já instalados, verificar compatibilidade, verificar novas versões do Sonar e gerenciar automaticamente a matriz de compatibilidade de plugins.

A nova versão do Sonar também suporta o Maven 3 para build de aplicações e análise de código. A InfoQ conversou com Olivier Gaudin, membro da equipe do Sonar, sobre as novas funcionalidades:

InfoQ: Quais são os próximos passos para a funcionalidade de regras de arquitetura?

Nesta versão inicial, as regras de arquitetura já oferecem a possibilidade de definir regras simples, como "uma classe / pacote A não deve ser utilizado pela classe / pacote B". A evolução natural desta funcionalidade é a possibilidade de descrever regras complexas através de uma DSL, com o intuito de definir camadas de arquitetura e depois definir regras como: camada A poderá ser usada somente pela camada B ou C. Graças a esta funcionalidade do Sonar, a necessidade de utilizar outras ferramentas para monitrar o design do projeto será apenas ocasional.

InfoQ: Quais são os próximos objetivos do Sonar?

O nosso principal objetivo é tornar o sonar uma plataforma completa para oferecer suporte total à Inspeção Contínua, provendo aos times de desenvolvimento a habilidade de mensurar e e gerenciar seus débitos técnicos. Nós identificamos três áreas que são os nossos próximos alvos para ampliar este suporte:

• O próximo passo vem no Sonar 2.5, com suporte para rastrear violações (já adicionadas no código fonte) e com suporte à diferentes visões no dashboard.
• Adicionar algum tipo de capacidade de revisar manualmente o código para adicionar, esconder, comentar e discutir defeitos na qualidade.
• Incorporar uma versão mais leve do Sonar no plugin sonar-eclipse para permitir revisão de código ao realizar commits de código.

Neste meio tempo, nós continuaremos adicionando novas linguagens utilizando a tecnologia de análise já desenvolvida na SonarSource e adaptá-las para novas regras em linguagens como C e COBOL por exemplo.

by

• Visualizar
• Responder
• Voltar ao topo