É comum ouvirmos falar sobre qualidade de produtos, serviços e afins. E também sabemos que não é uma realidade distante quando falamos de desenvolvimento de software, pois usufruirmos de processos e metodologias, testes de aceitação, funcionais e stress, todo esse conjunto afim de garantir a qualidade e excelência do que foi ou está sendo desenvolvido.

1. DevQA: Como medir qualidade de código? por Kamilla Queiróz
É comum ouvirmos falar sobre qualidade de produtos, serviços e afins. E também sabemos
que não é uma realidade distante quando falamos de desenvolvimento de software, pois
usufruirmos de processos e metodologias, testes de aceitação, funcionais e stress, todo esse
conjunto afim de garantir a qualidade e excelência do que foi ou está sendo
desenvolvido.
Mas temos como medir e garantir a qualidade do código que foi escrito por cada
desenvolvedor que compõe a nossa equipe? Dentro da visão de desenvolvimento o que pode
ser considerado como qualidade?
Dentro do estudo da engenharia de software se percebe diversos problemas que enquanto
desenvolvedores devemos procurar evitar, afim de chegar à um código fonte com qualidade.
É preciso observar duplicidade de código, métodos e classes com responsabilidades
relevantes, complexidade ciclomática elevada, ausência de testes de unidade e outros
pontos.
No entanto como a construção de um software dependente praticamente e principalmente
das pessoas que o constroem, alguns erros acabam surgindo mesmo que haja a utilização de
métodos e ferramentas de engenharia de software.
E ainda assim vendo em nossa equipe como detentora de boas práticas de programação,
mesmo que em um projeto com o desenvolvimento distribuído, precisamos visar a
manutenção e a garantia da qualidade do código e desta forma, erros podem ser encontrados
antes mesmo do software entrar em produção.
Desta forma uma série de atividades em conjunto conhecidas como "V & V" podem possuir o
objetivo de sanar esse ponto e por meio das métricas de software identificar erros e defeitos.
No tocante da Verificação estática, podemos relacionar com a Análise Estática de Código
(AEC), que nada mais é que uma referencia à análise automatizada, utilizando uma das
técnicas de inspeção de software dentro do processo de V & V (Validação e Verificação).
Cujo objetivo nada mais é que reduzir a quantidade de erros de um programa, chamando
então a atenção para suas anomalias, que podem ser geralmente erro de programação ou
omissões, cujos exemplos mais comuns são: um bloco catch vazio, uma conexão ou fluxo
não encerrado, perda de referência nula e também comparação de objetos com '=='. E
o que pode ser verificado por meio desses verificadores estáticos são regras de estilo e erros.
Para o ponto de Verificação de Regras de Estilo - Style Checker - que tem por papel a
verificação da conformação de um dado código fonte, quanto a sua definição de estilo de
programação, tais como abertura de chaves, ordem de declaração, javadoc e outros. Essa
abordagem certamente irá ajudar na prevenção de certos tipos de erros e consideravelmente
melhorar a qualidade do software. Todavia observe, essas violações em regras de estilo, nem
sempre são necessariamente erros.
E para a Verificação de Erro - Bug Checker - tem-se uma ferramenta voltada para a detecção
automática de erro, onde busca-se a comparação de objetos sem utilização de equals, a
concatenação de strings em laços de repetição e também fluxo não encerrado. Veja ainda
que, os resultado podem em vezes não ser defeitos reais, mas usados e vistos como um sinal
de alerta.
Assim temos como principais benefícios para a utilização de um verificador estático, os
seguintes pontos:

2. 1 - Erros e códigos de risco são encontrados mais facilmente;......................................
2 - Programadores passam a ter uma visão analítica objetiva, que possibilita e ajuda no
reconhecimento de onde os mesmo foram ou não precisos e desatentos;...........................
3 - Líder de projeto adquire uma oportunidade de estudar o código, seu projeto e também
sua equipe, passando a possuir uma perspectiva diferenciada;........................................
4 - Com a exclusão de determinadas classes de defeitos, a equipe se encontra concentrada
em outros tipos de eficiência do projeto.
E quanto as métricas onde cada qual mede um aspecto, algumas das mais relevantes são:
- 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.
No entanto vem à tona a questão que precisa ser respondida é "como é possivel calcular
efetivamente essas métricas?".
Várias são as ferramentas disponíveis e utilizadas para essa medição, algumas delas para
determinadas métricas e outras são soluções, que oferecem pacotes de métricas que podem
ser utilizadas para monitorar o código de maneira bem simples. Também há ferramentas que
auxiliam na comparação de código em um determinado período de tempo e possibilita a
criação de gráficos que apresentam a evolução do software.
Um ferramenta boa para gerar essas métricas é o SonarQube. Antigamente apenas conhecido
por Sonar, se trata de uma ferramenta web open-source utilizada para gerenciar a qualidade
de código e tem a cobertura de sete (7) categorias: Arquitetura e Design, Comentários,
Duplicação de código, Padrões de codificação, Testes (cobertura de código),
Complexidade ciclomática e Bugs em potencial. E detalhe, tudo é gerado através de uma
análise completa do código e os resultados são apresentados por meio de uma interface web,
em forma de dashboard. Como visto pelas imagens abaixo:

3. Além dos pontos citados, outros
• interface web bonita e bem organizada;
• ótima customização -
• vasta documentação;
• o SonarQubr se integra com vários servidores de integração contínua;
• possui plugin para integração com o Eclipse
rodadas direto na IDE;
Uma iniciativa brasileira nesse sentido
desenvolvimento, do brasileiro Mauricio Aniche, que traz em suas análises informações
quanto ao tamanho do projeto
commits, a quantidade de vezes que erros
números de erros, assim como também informações quanto a complexidade do código fonte,
identificando a quantidade de linhas de códigos
evolução desta. Como pode ser visto na imagem a seguir
Além dos pontos citados, outros podem chamar bastante a atenção:
interface web bonita e bem organizada;
- é possível criar novos dashboards, adicionar e remover widgets;
vasta documentação;
o SonarQubr se integra com vários servidores de integração contínua;
lugin para integração com o Eclipse - possibilitando que todas as regras sejam
rodadas direto na IDE;
Uma iniciativa brasileira nesse sentido é a Code Sheriff, ainda em fase de melhoria e
do brasileiro Mauricio Aniche, que traz em suas análises informações
tamanho do projeto, a frequência com que os desenvolvedores realizam
quantidade de vezes que erros são escritos, quais arquivos possuem o maior
, assim como também informações quanto a complexidade do código fonte,
quantidade de linhas de códigos e as suas evoluções,
evolução desta. Como pode ser visto na imagem a seguir:
criar novos dashboards, adicionar e remover widgets;
o SonarQubr se integra com vários servidores de integração contínua;
possibilitando que todas as regras sejam
ainda em fase de melhoria e
do brasileiro Mauricio Aniche, que traz em suas análises informações
frequência com que os desenvolvedores realizam
quais arquivos possuem o maior
, assim como também informações quanto a complexidade do código fonte,
e as suas evoluções, complexidade e

4. Valendo assim dedicação quanto a implantação destas ferramentas e aperfeiçoamento para o
ganho na garantia e na qualidade do código escrito.
Desta forma, posso considerar que a análise
de inspeções de software e sendo ela eficaz na busca de defeitos relacionados aos princípios
de programação e à manutenabilidade.
E tenho alguns itens que devo considerar quando for implantar uma ferramenta de métrica de
código:
- Não começar com o código já existente
de erros de código, aparentemente errado para as regras da ferramenta,
desestimuladar. Assim, é interessante sempre começar no início do projeto.
- Customizar as regras habilitadas da ferramenta
estado da arte, ou seja, vem com as regras mais relevantes
da ferramenta, então desta forma é bom avaliar quais as métricas realmente valem à pena
pra o seu projeto.
- Incluir na integração Contínua
durante a integração contínua, mas também
ciência dos valores da métrica na máquina dele. Por mais que existam dashboards para
mostrar gráficos de evolução, é importante
como está seu código e se sentir
- Corrigir ou não os erros apontados
corrigir os erros apresentados, é mais uma questão de gestão do que puro preciosismo da
equipe, ou seja, se é importante pra o cliente
modificabilidade, será também importante incluir isso também dentro do backlog para
correção.
- Analise o nível de modificabilidade
estão levando mais ou menos tempo, e se o
Valendo assim dedicação quanto a implantação destas ferramentas e aperfeiçoamento para o
ganho na garantia e na qualidade do código escrito.
Desta forma, posso considerar que a análise de código-fonte automatizada é uma das técnica
de inspeções de software e sendo ela eficaz na busca de defeitos relacionados aos princípios
de programação e à manutenabilidade.
E tenho alguns itens que devo considerar quando for implantar uma ferramenta de métrica de
Não começar com o código já existente - A equipe vai perceber uma quantidade elevada
de erros de código, aparentemente errado para as regras da ferramenta, e isso tende à
desestimuladar. Assim, é interessante sempre começar no início do projeto.
Customizar as regras habilitadas da ferramenta - As ferramentas sempre vêem com o
estado da arte, ou seja, vem com as regras mais relevantes habilitadas de acordo
da ferramenta, então desta forma é bom avaliar quais as métricas realmente valem à pena
Incluir na integração Contínua - É importante incluir a verificação do código a cada commit
durante a integração contínua, mas também permitir ao desenvolvedor a possibilidade de ter
ciência dos valores da métrica na máquina dele. Por mais que existam dashboards para
mostrar gráficos de evolução, é importante que desenvolvedor possa verificar localmente
como está seu código e se sentir seguro a commitar as alterações
apontados é uma questão de gestão - Se sua equipe validou não
corrigir os erros apresentados, é mais uma questão de gestão do que puro preciosismo da
equipe, ou seja, se é importante pra o cliente um código com um nível bom de
modificabilidade, será também importante incluir isso também dentro do backlog para
Analise o nível de modificabilidade - É importante acompanhar se as issues de correção
estão levando mais ou menos tempo, e se o software está com os números de defeitos
Valendo assim dedicação quanto a implantação destas ferramentas e aperfeiçoamento para o
fonte automatizada é uma das técnica
de inspeções de software e sendo ela eficaz na busca de defeitos relacionados aos princípios
E tenho alguns itens que devo considerar quando for implantar uma ferramenta de métrica de
A equipe vai perceber uma quantidade elevada
e isso tende à ser
As ferramentas sempre vêem com o
de acordo com a visão
da ferramenta, então desta forma é bom avaliar quais as métricas realmente valem à pena
É importante incluir a verificação do código a cada commit
permitir ao desenvolvedor a possibilidade de ter
ciência dos valores da métrica na máquina dele. Por mais que existam dashboards para
que desenvolvedor possa verificar localmente
Se sua equipe validou não
corrigir os erros apresentados, é mais uma questão de gestão do que puro preciosismo da
um código com um nível bom de
modificabilidade, será também importante incluir isso também dentro do backlog para
É importante acompanhar se as issues de correção
software está com os números de defeitos

5. aumentando ou diminuindo, ou seja, se a sua modificabilidade está melhorando. Uma boa
avaliação desses números é conseguir ter correções mais rápidas e sem efeitos colaterais.
Finalizando com o destaque da importância da verificação estática após a compilação e
também antes de uma revisão de código manual, possibilitando assim a obtenção de uma
indicação de correção adequada para então, iniciar a realização dos testes.
Links Relacionados:
• SonarQube
• Documentação SonarQube
• Demo SonarQube
• CodeSheriff
• Demo CodeSheriff
• Plugin Integração com Eclipse
• Ferramenta JetBrains
Ferramenta NCover
Publicado originalmente em O Tapioca: http://www.otapioca.com.br/?p=2354