Você já deve ter ouvido falar sobre a importância da qualidade de um produto ou serviço certo?

Diversas áreas se preocupam com isso, da construção civil e seus prédios, à um médico ao realizar uma cirurgia. Mas e na área de desenvolvimento de software, quais ferramentas temos a disposição para garantir a qualidade e excelência de nosso produto, o software? Temos diversas respostas para estas pergunta: metodologias e processos, testes de aceitação, testes funcionais, testes de stress. Estas ferramentas tem por objetivo garantir a qualidade a nível de cliente, fazendo com que o produto atenda as demandas corretamente para as quais foi projetado.

Mas e para nós desenvolvedores, o que pode ser considerado como um software de qualidade? O estudo da engenharia de software nos remete a diversos problemas que o desenvolvedor deve procurar evitar para obter código fonte de qualidade. Duplicidade de código, métodos e classes com muitas responsabilidades, alta complexidade ciclomática, ausência de testes unitários, entre outros.

Partindo da premissa de que o desenvolvedor conhece as boas práticas de programação, controlar a propagação destes fatores indesejáveis, em um projeto pequeno pode ser fácil. Mas atualmente a realidade é outra, projetos tendem a serem escaláveis e crescerem ao longo do tempo. Além disso dificilmente o desenvolvedor irá trabalhar sozinho, o desenvolvimento distribuído já é realidade na maioria da empresas. Nesses casos é muito fácil a equipe perder o controle da dimensão do software e de seus problemas.

E é neste cenário que entram as métricas de software. Existem diversas métricas, cada uma medindo um aspecto do software. Abaixo seguem alguns exemplos:

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.

Estas métricas são apenas um exemplo, existem outras diversas. Mas a pergunta que fica é como calcular de forma efetiva estas métricas? Existem diversas ferramentas utilizadas para medição de software, algumas servem para métricas específicas, mas existem soluções como Sonarqube que oferecem um pacote de métricas que podem ser utilizadas pelos desenvolvedores para monitorar o estado do código de maneira simples e rápida. Algumas destas ferramentas também auxiliam a comparação do código em um período de tempo, assim possibilitando a criação de gráficos que mostrem a evolução de nosso software.

Um bom exemplo disso seria um gráfico do tipo Cobertura de testes X Complexidade ciclomática. Quando evoluímos o software inserindo novas features, devemos ter o cuidado de não inserir complexidade desnecessária, visando a boa evolução do código. Abaixo segue um exemplo de como esse tipo de gráfico nos fornece um rápido feedback sobre o código:

Gráfico de complexidade do framework Struts

Este gráfico mostra claramente que o framework Struts inseriu alguma funcionalidade que aumentou a complexidade do código drasticamente, e que a cobertura de código caiu quase na mesma proporção.

Como vimos o monitoramento das métricas de software pode ser essencial para a manutenção da saúde de nosso código. Cabe a nós desenvolvedores, ou aos times que resolverem adotar esta prática, utilizarem com parcimônia. De nada adianta possuirmos um dashboard com diversas métricas se a maioria não faz sentido para o nosso caso. Também vale ressaltar que as medições devem servir como base para planos de ação, caso contrário se tornam apenas números. Para começar, escolha de 3 a 5 métricas e ataque os pontos críticos, com o tempo você pode adotar outras, mas sempre visando a melhoria continua e consequentemente a qualidade de seu código.