Existe avaliação e garantia de qualidade no seu código durante o desenvolvimento e depois do deploy?

Se você é desenvolvedor de software já há um tempo, com certeza já se pegou olhando para aquele código antigo na sua IDE, nos seus repositórios no Github ou no Bitbucket e sentiu uma vontade quase compulsória de ̶ ̶d̶e̶l̶e̶t̶á̶-̶l̶o̶ refatorá-lo, seja para deixá-lo mais legível, eliminar alguns code smells ou até mesmo atualizá-lo para utilizar novas features da linguagem escolhida.

No primeiro texto sobre qualidade de código com Java, falamos sobre um conjunto de dicas de boas práticas bem simples que devem ser levadas em conta no momento em que você está desenvolvendo seu código. Entretanto, sabemos que esse nível de conhecimento e fluidez na escrita de um código bom só é adquirido com tempo, esforço, prática e bastante estudo.

Você leitor deve estar se perguntando: existe uma forma de acelerar um pouco esse processo de aprendizado de uma equipe de desenvolvimento de software? Sim, na verdade, muitas equipes utilizam a etapa de code review para esse fim também. Mas, o code review deveria ser utilizado puro e exclusivamente para esse tipo de avaliação? Não existe ferramentas melhores para avaliar o código e garantir que o desenvolvedor está respeitando convenções já estabelecidas?

SIM! Nesse artigo, vamos falar sobre os tipos de ferramentas que você pode utilizar para descobrir se o seu código está bem construído ou não: os analisadores estáticos de código (AEC).

Analisadores estáticos de código (AEC)

A análise estática é uma referência à análise automatizada, que visa, por meio das métricas de software, identificar erros e defeitos no código-fonte. Dentre os benefícios da utilização de um AEC estão:

1. É possível encontrar com mais facilmente os erros, trechos de risco e code smells;
2. Os analisadores promovem uma visão analítica mais objetiva do código, possibilitando desenvolvedores reconhecerem pontos de desatenção;
3. As lideranças de um projeto podem estudar o código com maior cuidado e identificar, por meio de uma perspectiva diferenciada, fatores ou pontos de falha técnica que precisam ser melhorados na equipe;
4. Uma vez que problemas são identificados e excluídos do projeto, a equipe pode se concentrar em outros tipos de melhorias e evoluções.

Existem ferramentas pagas e MUITAS ferramentas gratuitas que fazem um bom trabalho de análise de qualidade. Em geral, podemos dividir as funções dessas ferramentas em três: os analisadores de código baseados em métricas de qualidade (Metric Tools), os Style Checkers e os Linters.

Analisadores de código baseados em métricas (Metric Tools)

São ferramentas de software ou plugins para uma IDE específica que medem vários aspectos de qualidade do projeto analisado, em geral, em relação à:

• Complexidade: avalia o número de linhas de código, de classes, de métodos, de atributos e a árvore de herança. Servem para identificar se um sistema tem muitos desvios do fluxo principal do código (tem muitos if, switch, for ou while — a complexidade ciclomática), se temos classes e métodos muito extensos ou o uso de herança (profundidade máxima da árvore de herança e número de filhos, por exemplo). As medidas mais comuns utilizadas para esse fim são: LOC (Lines of Code), NOM (Number of Methods), NOA (Number of Attributes), DIT (Depth of Inheritance Tree), CC (Cyclomatic Complexity) e WMC (Weight Methods per Class).
• Acoplamento: avalia o relacionamento dependência entre os módulos de um software. Basicamente, verifica o quão um módulo depende de um outro para funcionar. O ideal é que as partes de um software sejam mais desacoplados o possível, ou seja, que não dependam de outros para fazer sua funcionalidade básica (baixo nível de acoplamento). As medidas mais comuns são: RFC (Response for a Class) e CBO (Coupling between objects).
• Coesão: se refere ao relacionamento que os membros de um módulo possuem, se possuem uma relação mais direta e importante. Um código de alta coesão ou simplesmente coeso é um código em que seus membros estão intimamente ligados por um objetivo comum, como dito pelo Uncle Bob, por uma responsabilidade única. As medidas mais comuns são: LCOM (Lack of Cohesion of Methods) em várias versões, TCC (Tight Class Cohesion) e LCC (Loose Class Cohesion).

A maioria das ferramentas disponíveis são open-source, podem atuar sobre o código fonte e/ou bytecode e ser instaladas como plugin no Eclipse. Outras são aplicações pagas, com versões trial. Abaixo, temos uma listinha de ferramentas mais populares do mercado e oriundas de trabalhos acadêmicos em Engenharia de Software:

• Metrics: é a mais antiga dessa lista. Com os primeiras implementações disponibilizadas no início dos anos 2000, o Metrics é um plugin para o Eclipse que analisa código Java. Calcula o valor de 23 métricas em nível de classe e projeto, com média e desvio padrão, além de possuir um analisador de dependência cíclica entre pacotes. A inspiração do autor para a implementação das métricas foram: o livro Object-Oriented Metrics, measures of Complexity, do Brian Henderson-Sellers (1996); e, o artigo OO Design Quality Metrics, An Analysis of Dependencies (1994) e o livro Agile Software Development, Principles, Patterns and Practices (2002), ambos do Robert C. Martin (a.k.a Uncle Bob).

Exemplo do Grid com resultados de medidas do Metrics (Fonte: http://metrics.sourceforge.net/)

• SonarQube: é uma plataforma de qualidade de software, escrita em Java, com integração com Eclipse e o Maven, que utiliza diversas ferramentas para obter métricas de software. Temos no Sonar, sem contar as métricas voltadas para teste, 40 métricas disponíveis para avaliar projetos Java. Dentre essas métricas, as mais conhecidas estão o LOC (Lines of Code) e o LCOM4 — Lack of Cohesion of Methods, versão 4, que avalia suspeitas de violação do princípio SRP (Single Responsability Principle — a tal da responsabilidade única que citei no item de Coesão), verificando quantos “componentes conectados” existem dentro de uma classe. Além disso, possui um dashboard bem completo, que demonstra a quantidade de bugs do código, as vulnerabilidades, os code smells e a cobertura de teste do projeto.
• Understand: é uma ferramenta desenvolvida pela Scitools. Disponibiliza 29 métricas de orientação a objetos, como o CBO e o DIT (profundidade máxima da árvore de herança), e 27 métricas de complexidade de código como complexidade ciclomática. A empresa disponibiliza uma versão trial de 15 dias, e, consequentemente, a versão mais completa é paga (e o preço de uma licença é BEM salgado). Além disso, roda nos três principais SO’s: Linux, Mac e Windows.
• JDepend: ferramenta desenvolvida pelo Mike Clark, da Clarkware Consulting, Inc., que analisa dependências de um pacote Java em termos de extensibilidade, reusabilidade e manutenibilidade. As métricas implementadas no JDepend são as chamadas “Martin Metrics”, referenciadas no livro Designing Object Oriented C++ Applications using the Booch Method (Prentice Hall, 1995) do nosso querido e sempre citado Uncle Bob: Afferent Coupling (Ca — Acoplamento Aferente), Efferent Coupling (Ce — Eferente), Abstractness (A), Instability(I) e Distance from the Main Sequence (D).
• o3smeasures: (MOMENTO JABÁ ABSUUUUURDO*) é uma ferramenta que desenvolvi no meu mestrado. O o3smeasures, abreviação para Object-oriented open (o3) source measures, implementa as 15 métricas mais utilizadas em pequisas sobre eficácia da qualidade interna de projetos Java (resultado extraído de uma revisão sistemática), por exemplo, LOC (Lines of Code), NOM (Number of Methods), DIT (Depth of Inheritance Tree), WMC (Weight Methods per Class), TCC (Tight Class Cohesion), RFC (Response for a Class) e CBO (Coupling between objects) + a medida Number of Classes (número de classes). Após a medição do projeto, é possível extrair o resultado da medição em arquivos .csv e .xml, visualizar quais são as classes com maior número de problemas técnicos e identificar as falhas de qualidade por fatores.

Style Checkers

São os verificadores de regras de estilo de programação. Analisam se um dado código está em conformidade com as convenções de uma linguagem. Por exemplo, para o Java, a verificação deve ser feita baseada no Java Code Conventions, tais como abertura de chaves, ordem de declaração, javadoc e outros.

Essas convenções são definidas em arquivos ou guides conhecidos como profile que podem ser importados em IDE’s como Eclipse, Netbeans ou IntelliJ. Cada uma dessas IDE já possui seu Style Guide default. Caso você deseje utilizar algum style guide específico, você pode importá-lo na sua IDE. Um dos style guide externos mais utilizados por devs é o Google Java Style Guide. Caso queira customizar um style guide, podemos criar um profile acessando o menu Window -> Preferences -> Java -> Code Style -> Formatter. Assim, todas as vezes em que usamos o comando Ctrl+Shift+F na classe, o código é formatado seguindo as configurações feitas por você.

Dentre as ferramentas mais conhecidas nessa categoria está o Checkstyle. Nessa ferramenta são checadas a ordem de declaração nos métodos, padrão de nomenclatura, posição da cláusula default em instruções switch, entre outras. Entretanto, cabe ressaltar que, essas violações em regras de estilo, nem sempre são necessariamente erros. Entretanto, podem ser importantes para evitar problemas de conflitos de formatação de arquivos durante merges e rebases da vida.

Linters

São verificadores de qualidade estrutural do código. Os linters ajudam a identificar e corrigir problemas sem ser necessária a execução da aplicação. As ferramentas dessa categoria têm como função relatar os problemas encontrados baseado no nível de severidade e descrevendo do que se trata o problema.

Esses problemas relatados nos linters, geralmente são classificados em 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.

Dentre as ferramentas mais utilizadas nessa categoria estão:

• SpotBugs: o antigo FindBugs, é uma ferramenta voltada à verificação de erros desenvolvida pela University of Maryland. O SpotBugs suporta a verificação de mais de 400 padrões de erros e a versão mais atual, a 3.0.0, já tem suporte para Java 8. Possui integração com Ant, Maven, Gradle e com o Eclipse (como plug-in).
• PMD: O PMD é uma ferramenta que analisa falhas de programação comuns, como variáveis não usadas, blocos catch vazios, criação desnecessária de objetos e assim por diante. Também tem um detector de ctrl+c e ctrl+v (muito bom isso!!!), para verificar trechos de código duplicados. Tem integração com várias ferramentas conhecidas como Eclipse, Netbeans, JBuilder, JDeveloper, IntelliJ e como plugin do Maven (pode ser habilitado ao executar o goal “test”) e do Gradle.
• SonarLint: dessa listinha de linters (e também de AEC’s), o Sonar, sem dúvida, é a ferramenta mais completa disponível. Na sua versão Lint, possui diversas funcionalidades muito úteis para o seu dia-a-dia, que as outras ferramentas não têm. Por exemplo, na análise On-the-fly, mostra os problemas enquanto você codifica. Sublinha os novos problemas para que você ainda possa se concentrar no código que está sendo escrito. Na análise On changes, lista os problemas encontrados em todos os arquivos que você adicionou e atualizou. Em resumo, com SonarQube + Lint é combo mais preciso nas identificações de erro e de déficit técnico no seu projeto. Além disso, tem integração com as IDE’s Eclipse, Visual Studio, VS Code, Atom e IntelliJ.

Exemplo de análise On-the-fly do SonarLint (Fonte: https://www.sonarlint.org/eclipse/index.html)

Exemplo do dashboard do SonarQube (Fonte: https://www.sonarqube.org/)

Apesar do foco do artigo ter sido ferramentas de avaliação e garantia da qualidade de código em Java, no Github temos diversos projetos que atendem à essa necessidade em diferentes linguagens. Algumas das ferramentas que citei no texto também disponibilizam métricas e funcionalidades para outras linguagens como C, C++, C#, Groovy, Javascript, PHP e Python. Nesse link, temos uma coleção de projetos muito bem avaliados que podem ser muito úteis no seu dia-a-dia.

Como o título do artigo mesmo diz, em todo projeto e equipe que preza por qualidade, deve sim existir avaliação e garantia de qualidade no seu código durante o desenvolvimento e depois do deploy. A automação disso via uma ou mais dessas ferramentas (vai depender dos seus objetivos) é o caminho para o alcance dessa qualidade. Pense nisso!

Espero que tenham gostado do post. Abraços e até o próximo texto!

*Se você é nerd raiz, pegou essa referência rsrs...

Referências

1. Código Limpo: Habilidades Práticas do Agile Software (Robert C. Martin, 2011)
2. Github: https://github.com/
3. SonarQube: https://www.sonarqube.org/
4. PMD: https://github.com/
5. SpotBugs: https://spotbugs.github.io/
6. Understand: https://scitools.com/
7. Checkstyle: http://checkstyle.sourceforge.net/
8. JDepend: https://github.com/clarkware/jdepend
9. Metrics: http://metrics.sourceforge.net/update