Análise contínua de qualidade do software

Encontre rapidamente problemas que podem impactar a qualidade do seu software.

Todos desenvolvedores, engenheiros e arquitetos de software desejam e fazem o seu máximo em busca do ápice da qualidade do seu software, mas, no fundo, sabem o quão utópico é atingir um patamar perfeito. Um código que você olha e diz que não mudaria nada mais. Um código sem bugs, simples, mesmo com regras de negócio complexas, legível por qualquer estudante de filosofia, manutenível por qualquer estagiário e capaz de performar absurdamente mesmo em um servidor windows.

A qualidade do software é um ciclo infinito. Análises e refatorações são ações que podem ser feitas pro resto da sua vida em um mesmo código. Quando estamos trabalhando em um time, em um mesmo projeto, manter tudo isso é ainda mais trabalhoso, afinal, a cabeça de cada um funciona e acredita em coisas totalmente distintas.

Em um certo momento parece que todo software “fica problemático” (normalmente quando liberado em produção), e nesse momento, todo aquele cuidado inicial com a arquitetura, o reaproveitamento do código, o padrão da escrita, os princípios do Clean Code, vão tudo pro saco.

E eu tenho que concordar, porque realmente é muito difícil controlar tudo isso apenas com a análise humana durante um pull request.

Dado que sua aplicação possui o mínimo de automatização — já podemos considerar CI/CD obrigatório, né? — neste artigo vou apresentar algumas ferramentas (SonarQube, Codacy e Code Climate) que podem te ajudar a automatizar o seu processo de análise da qualidade do seu software e quais principais problemas elas podem resolver. Essas ferramentas também são conhecidas como ferramentas de Code Quality Analysis, Continuous Inspection ou Continuous Improvement.

Principais problemas que iremos analisar

• Complexidade Ciclomática → É uma métrica de engenharia de software que serve para mensurar a complexidade de uma determinada parte do software (uma classe, um método, etc) a partir da contagem dos possíveis caminhos independentes que ele pode executar até o seu fim. Um caminho independente é aquele que apresenta pelo menos uma nova condição (possibilidade de desvio de fluxo) ou um novo conjunto de comandos a serem executados.
• Código Duplicado → É, basicamente, aquele famoso ctrl+c /ctrl+v nos trechos de código ao invés de adaptar a arquitetura da aplicação para o compartilhamento do código específico. Essas ferramentas são capazes de identificar não só códigos idênticos, mas também códigos que possuem o mesmo fluxo mas com partes diferentes na sua escrita (como só mudar o nome da variável).
• Vulnerabilidades e Bugs → Um pouco subjetiva, essa análise pode variar bastante de ferramenta para ferramenta. Tem basicamente a função de identificar códigos que “quebrariam” a sua aplicação. Por exemplo, ao declarar uma variável sem instancia-la e logo após tentar acessar uma propriedade dela, o que causaria uma exceção de Null Reference. Outro exemplo seria algum trecho de código sujeito a injeção de código / SQL;
• Padronização / Estilo → Garantir que todo código esta escrito da mesma maneira: Nome de variáveis locais, propriedades, constantes, métodos, classes, estrutura do código em si e dos arquivos do projeto, etc. Também indica práticas que você não deveria utilizar, como usar o comando goto ou manter um fluxo de um switch sem o default. Imagine que esse ponto basicamente é uma análise “lint” bem completa sobre o seu código.
• Débito Técnico → Com as informações citadas anteriormente, a maioria das ferramentas é capaz de calcular e mensurar o esforço necessário (normalmente metrificado em “horas” ou “dias”) para corrigir os possíveis problemas apontados e resolver todos ou cada débito técnico.
• Cobertura de Testes → Que porcentagem do seu código é testado? Podemos entender que a cobertura está ligado ao número de linhas, métodos ou fluxos que são executadas durante os seus testes. Analisar a cobertura de teste em consideração de todas os caminhos independentes (vide explicação no tópico de complexidade ciclomática) costuma ser a melhor maneira de garantir que o teste realmente atinge todos os cenários lógicos possíveis.
• Métricas → Por fim, cada ferramenta tem a sua própria métrica final, baseada nas outras já conhecidas, citadas nos tópicos acima, deixando claro como o seu projeto está nos aspectos confiabilidade, complexidade, manutenibilidade, segurança, testes, duplicações e problemas em geral.

Ferramentas

A seguir falaremos de 3 ferramentas que podem te ajudar a coletar informações e fazer a análise da qualidade do seu código sempre que um novo código for adicionado ou alterado no seu projeto.

Todas elas possuem a sua versão free e a versão paga, sendo a versão free basicamente aplicável em projetos open-source (repositórios públicos) e a versão paga em projetos fechados (repositórios privados).

Elas podem ser utilizadas em diversas linguagens de programação como C#, Java, Javascript, Python, Ruby, Go, Swift, Scala, Kotlin, etc.

Codacy

Para fazer a integração, basta acessar o site do Codacy e criar a sua conta com o GitHub ou BitBucket. Após autorizar o login com uma das duas opções, o Codacy já tem acesso aos seus repositórios. A partir daí é só selecionar o projeto e a análise do seu código será efetuada automaticamente a cada novo commit em seu repositório.

Configurando o seu primeiro projeto no Codacy.

É possível definir os padrões de análise que deseja que ele execute no menu Code Patterns.

A interface é bem simples e fácil de entender. Agora, você já pode acompanhar as suas métricas de qualidade no Codacy e adicionar uma badge de qualidade no seu projeto.

Para configurar e enviar o code coverage report e centralizar toda análise de qualidade e cobertura de testes no mesmo lugar, é necessário coletar dados dos testes durante o seu processo de CI e utilizar o Codacy Coverage Report. Para utiliza-lo é necessário acessar as configurações do seu projeto e copiar o Project Token.

Segue abaixo um script de exemplo para uma aplicação dotnet com seu build acontecendo um um ambiente linux:

Enviando relatório dos testes para o Codacy.

O Codacy não possui uma badge nativa para exibir a porcentagem da cobertura de testes. Mas, você pode utilizar Shields.io para exibir uma badge com a cobertura que você enviou para o Codacy.

É possível executar o Codacy offline, porém apenas com uma licença enterprise. Também é possível adicionar um arquivo .codacy.yml no seu projeto para manter as configurações do projeto em um arquivo, de forma reaproveitável.

Code Climate

A integração com o CodeClimate é muito parecida com a integração com o Codacy, porém atualmente só integra com o GitHub. Para criar a sua conta, acesse o site do CodeClimate e crie a sua conta utilizando o GitHub na ferramenta Quality. Após autorizar o GitHub, o CodeClimate tem acesso aos seus repositórios e é só selecionar o projeto e a análise do seu código também será efetuada de maneira automática a cada novo commit.

Configurando o seu primeiro projeto no CodeClimate.

É possível definir os padrões de análise que deseja que ele execute no menu Repo Settings > Maintainability e adicionar plugins para estender as análises em Repo Settings > Plugins .

A interface, assim como o Codacy, é bem simples e fácil. Nesta etapa, sua integração já está pronta para exibir dados da análise do seu código e adicionar uma badge de qualidade no seu projeto.

Para configurar e enviar o code coverage report também é necessário coletar dados dos testes durante o seu processo de CI e utilizar uma ferramenta própria, o CodeClimate Test Reporter. Para utiliza-lo é necessário acessar as configurações do seu projeto e copiar o Test Reporter ID.

Abaixo um script de exemplo para uma aplicação dotnet com seu build realizado um um ambiente linux:

Enviando relatório dos testes para o CodeClimate.

Ao contrário do Codacy, o CodeClimate possui badge própria para a exibição do code coverage do teste.

É possível rodar o CodeClimate offline com docker e fazer seus testes, mas por exigir que o código seja montado como um volume, seu uso fica um tanto limitado à etapa de desenvolvimento. Também é possível adicionar um arquivo codeclimate.yml com as suas configurações.

SonarQube

SonarQube (ou, conhecido na nuvem como, SonarCloud) é (na minha opinião) a integração com mais recursos, porém, mais trabalhosa e complexa, de acordo com o nível de customização que você desejar chegar. No SonarCloud você tem a opção de integrar com o GitHub, Bitbucket ou Azure DevOps. Para criar a sua conta, acesse o site do SonarCloud e crie a sua conta utilizando uma das opções disponíveis. Após autorizar o login, o Sonar tem acesso aos seus projetos. Selecione o projeto e gere os dados necessários (chave da organização, chave do projeto e token de acesso) para fazer o upload do artefato de análise do seu código e do code coverage.

Diferentemente do Codacy e do CodeClimate, o report de qualidade é gerado juntamente do build e o seu upload é feito no mesmo momento que o code coverage. Integrado ao seu CI, você garante que ele será executado automaticamente a cada novo commit em seu repositório.

Configurando o seu primeiro projeto no SonarCloud.

Com uma interface mais completa, no início você pode achar que o Sonar possui muitas funcionalidades (e realmente tem!), mas o básico e mais importante para a análise da qualidade você será capaz de interpretar rapidamente e com o tempo vai evoluindo o seu conhecimento na ferramenta.

Nesta etapa da sua integração, ainda é necessário executar o processo de build e teste para gerar o report de qualidade e de code coverage para que possa ser possível visualizá-lo no SonarCloud. Para gerar o report é necessário utilizar o Sonar Scanner específico para a sua linguagem / compilador.

Abaixo um script de exemplo para uma aplicação dotnet com seu build acontecendo um um ambiente linux:

Após o processo acima (build, teste e envio do report) o painel do Sonar estará populado com a análise e você já pode obter a badge de qualidade e de teste para inserir no seu projeto.

É possível rodar o SonarQube na sua própria infra como serviço ou utilizando docker e fazer os seus testes ou até mesmo manter o seu serviço on premise.

Para definir os padrões de análise que deseja de maneira customizada, você deve estar rodando o seu serviço on premise (ou seja, na versão cloud não é possível) e acessar as configurações no menu Rules e Quality Profiles.

Além de tudo que foi dito, o Sonar possui uma penca de configurações avançadas, e, se você gostou dele, recomendo a leitura da documentação oficial.

Existem diversas ferramentas além das citadas acima mas citei as minhas preferidas. O importante em si, não é qual a ferramenta você está utilizando, mas sim estar utilizando alguma ferramenta para automatizar a coleta das métricas e fazer inspeção continuamente, acompanhando os resultados, tomando decisões e realizando ações para garantir e aumentar a qualidade do seu projeto.

Mas muita atenção! Isso não significa que você deve parar de fazer code review dos pull requests ou acreditar que a ferramenta irá trazer a qualidade de forma mágica.

Espero que esse artigo ajude muitas pessoas a pensarem mais sobre o assunto e sirva como incentivo para automatizar e melhorar a qualidade do seu software.

Projeto demo de integração com todas ferramentas acima:
https://github.com/ThiagoBarradas/jsonmasking/blob/master/QA.md