DevQA

Prévia do material em texto

DevQA: Como medir a qualidade do código? 
 
É comum ouvirmos falar sobre qualidade de produtos, serviços e fins. Também 
sabemos que não é uma realidade distante quando falamos de desenvolvimento 
de software, pois usufruímos de processos e metodologias, testes de facilidades, 
funcionais e estresse com o objetivo 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 nossa equipe? Dentro da visão de desenvolvimento, o 
que pode ser considerado como qualidade? 
Dentro do estudo da engenharia de software se percebem diversos problemas 
que, enquanto desenvolvedores, devemos procurar evitar, afim de chegar a um 
código fonte de 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 depende basicamente 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. 
No tocante à Verificação estática, em relação à Análise Estática de Código 
(AEC) , que nada mais é que uma referência à análise automatizada, utilizando 
uma das técnicas de inspeção de software dentro do processo de V&V (Validação 
e Verificação). 
https://kamillaqueiroz.medium.com/?source=post_page-----6149fada1e--------------------------------
https://kamillaqueiroz.medium.com/?source=post_page-----6149fada1e--------------------------------
https://pt.wikipedia.org/wiki/Complexidade_ciclom%C3%A1tica
https://pt.wikipedia.org/wiki/Teste_de_unidade
Onde o objetivo nada mais é reduzir a quantidade de erros de um programa, 
então chamando a atenção para suas anomalias, que geralmente podem ser erros 
de programação ou omissões, tendo como exemplos mais comuns: um bloco 
catch vazio , uma conexão ou fluxo não fechado, perda de referência 
nula e também comparação de objetos com '==' . O que pode ser verificado 
por meio desses verificadores estáticos são regras de estilo e erros. 
Para a 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. Esse tipo de verificação certamente irá prevenir a prevenção de 
certos tipos de erros e melhorar consideravelmente a qualidade do 
software. Contudo, observemos que essas regras de estilo são evidentes, nem 
sempre são necessariamente erros. 
O outro tipo de verificação mais comum é a Verificação de Erro — Bug 
Checker — há ferramentas externas para a detecção automática de erro, 
buscando 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. Onde, o resultado 
pode em algumas 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 selecionador 
estático, os seguintes pontos: 
1- Erros e códigos de risco são encontrados mais facilmente; 
2- Os programadores passam a ter uma visão analítica objetiva, que possibilita e 
ajuda no reconhecimento de onde os mesmos foram ou não precisos e 
desatentos; 
3- Líderes de projetos adquirem uma oportunidade de estudar o código, seu 
projeto e também sua equipe, passando a possuir uma perspectiva diferenciada; 
4- Com exclusão de determinadas classes de defeitos, a equipe encontra 
especificações em outros tipos de eficiência do projeto. 
E quanto às métricas sobre 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 a métrica quando utilizada para 
fazer comparações. Um número maior de linhas de código não significa 
necessariamente que um software seja maior que outro. Por exemplo, diferentes 
linguagens de programação incomuns de número de instruções diferentes para 
executar 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 
http://www.objectmentor.com/omTeam/martin_r.html
http://www.devmedia.com.br/entendendo-coesao-e-acoplamento/18538
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 um pouco coesa. Assim como 
outras métricas, este valor não pode ser considerado totalmente verdadeiro. Em 
algumas graças, 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 é possível 
calcular efetivamente essas avaliações?” . 
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 pacotes de ofertas de 
métricas que podem ser utilizados 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. 
Uma 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 entrega , Testes (cobertura de 
código) , Complexidade ciclomática e Bugs em portencial . E detalhe, 
tudo é gerado através de uma análise completa do código e os resultados são 
http://www.sonarqube.org/
apresentados por meio de uma interface web, em forma de dashboard. Como 
visto pelas imagens abaixo: 
 
Além dos pontos citados, outros podem chamar bastante a atenção: 
• interface web bonita e bem organizada; 
- ótima customização — é 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; 
- possui plugin para integração com o Eclipse — possibilitando que 
todas as regras sejam rodadas direto na IDE; 
** esses itens disponíveis estão nos mais antigos do sonarQube, mas que 
agregam valor e apresentam informações de extrema relevância. 
Uma iniciativa brasileira nesse sentido é o Code Sheriff , ainda em fase de 
melhoria e desenvolvimento, do brasileiro Mauricio Aniche, que traz em suas 
análises informações sobre o tamanho do projeto , a frequência com que 
http://www.codesheriff.com/
os desenvolvedores realizam commits , a quantidade de vezes que 
erros são escritos , quais arquivos possuem o maior número de 
erros , assim como também informações sobre a complexidade do código fonte, 
identificando a quantidade de linhas de códigos e as suas 
evoluções,complexidade e evolução desta. Como você pode ver a imagem a 
seguir: 
 
 
Valendo assim dedicação de tempo e estudo para a implantação dessas ferragens 
e aperfeiçoamento para o ganho na garantia e na qualidade do código escrito. 
Desta forma, a análise de código-fonte automatizada é uma das técnicas de 
inspeções de software e sendo eficaz na busca de defeitos relacionados aos 
princípios de programação e à manutenabilidade. 
Tenho alguns itens que devo considerar ao implantar uma ferramenta de métrica 
de código: 
- 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 com a visão da ferramenta, então desta forma é bom 
avaliar quais as análises realmente valem a pena pra o seu projeto. 
- Incluir a 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 o desenvolvedor possa verificar localmente como está seu código 
e se sentir seguro ao cometer as alterações 
- Analisar o nível de modificabilidade — É importante acompanhar se os 
problemas de correção estão levando mais ou menos tempo, e se o software está 
com os números de defeitos aumentando ou diminuindo, ou seja, se sua 
modificabilidade está melhorando. Uma boa avaliação desses números é 
conseguir ter correções mais rápidas e sem efeitos colaterais. 
Finalizo dando destaque à 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.