É 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, funionais 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:
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 perspetiva 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 portencial. 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:
Além dos pontos citados, outros podem chamar bastante a atenção:
- interface web bonita e bem organizada;
- ótima customização - é possivel 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;
Uma iniciativa brasileira nesse sentido é a Code Sheriff, ainda em fase de melhoria e desenvolvimento, do brasileiro Mauricio Aniche, que traz em suas análises informações quanto ao tamanho do projeto, a frequência com que os desenvolvedores realizam commits, a quantidade de vezes que erros são escritos, quais arquivos possuem o maior 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 e as suas evoluções, complexidade e evolução desta. Como pode ser visto na imagem a seguir:
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 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 métricas realmente valem à pena pra o seu projeto.
-
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
-
Corrigir ou não os erros apontandos é 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 correção.
-
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 aumentando ou diminuíndo, 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 importancia da verificação estática após a compilação e também antes de uma revisão de código manual, possibilitanto assim a obtenção de uma indicação de correção adequada para então, iniciar a realização dos testes.
Links Relacionados:
Artigo publicado originalmente no portal O Tapioca e repostado em MihQueiroz.com.br.
