Início > Processo de Desenvolvimento > Qualidade de Código

Qualidade de Código

Já olhou para um código macarrônico feito em Java e teve a impressão de que estava olhando para um programa estruturado? Alguma vez já teve a oportunidade de analisar uma estrutura de classes tão acopladas que uma pequena alteração em qualquer uma delas causaria um colapso estrutural parecido com a retirada da carta base de um castelo de cartas? Isso significa que a qualidade do código e do design não está boa.

De Volta ao Básico

Escrever código é mais fácil do que lê-lo. Quando um desenvolvedor escreve código, ele deve ter em mente que o produto do seu trabalho será lido por outras pessoas no futuro. Portanto, há a necessidade de institucionalização de padrões de codificação para que todos na equipe falem a mesma língua. Em Java, um bom começo para a elaboração de um padrão é o livro Effective Java Programming Language Guide.

Para escrever um bom código, todo o desenvolvedor Java necessariamente deve ter bem claros os conceitos de orientação a objetos (classes, polimorfismo, etc) e da API do Java. Deve conhecer o funcionamento do Garbage Colletor, ciclo de vida das Threads, dos Servlets, como funciona um servlet container ou um EJB container, transações, como a heap é utilizada (young generation, tenured, etc ), mapeamento objeto-relacional. Deveria saber muito bem o básico do básico, que são estruturas de repetição, condicionais, tipos de dados, filas, pilhas, etc.

Espera-se que se o desenvolvedor conhece tudo que foi discutido seu código ficará claro e auto-documentado, ou seja, todos serão capazes de entendê-lo, mas na prática isso não acontece. Conhecer uma plataforma não é suficiente para nos tornarmos bons desenvolvedores. Para construir bom código, ainda precisamos entender e aplicar Design Patterns. Para os mais curiosos, Analysis Patterns também são muito úteis para aumentar a comunicabilidade de domínios de negócio bem conhecidos.

Se o código está caótico, há a possibilidade de aplicar técnicas de Refactoring. O catálogo de refactorings do Martin Fowler nos dá subsídios para melhorar muito a estrutura interna do código sem alterarmos seu funcionamento e também para melhorarmos a arquitetura de partes da aplicação. Para auxiliar o refactoring do código, há ferramentas especializadas como as que vêm integradas no IDE Eclipse.

Medindo a Qualidade da Arquitetura

Em Software, uma métrica se refere a aplicação de uma medida objetiva para determinação de certas características dos artefatos desenvolvidos. A qualidade de uma arquitetura pode ser medida em parte pela quantificação de seus graus de extensibilidade, reusabilidade e mantenabilidade. Essas qualidades são influenciadas pela inter-dependência dos artefatos.

Arquiteturas são mais extensíveis quando são independentes de detalhes de implementação, o que permite a criação de novas implementações sem modificação ou quebra de contratos existentes.

Essa independência tende a aumentar o potencial reuso de partes da arquitetura. Partes independentes da arquitetura contendo abstrações de alto nível podem ser extraídas de partes contendo detalhes de implementação.

A mantenabilidade da arquitetura é melhorada quando mudanças podem ser facilmente feitas sem que haja impacto em outras partes do sistema.

Sabendo que o objetivo de uma boa arquitetura é possibilitar extensibilidade, reusabilidade e mantenabilidade, podemos definir indicadores de código:

  • Quantidade de Classes e Interfaces: quantidade de classes concretas, abstratas e interfaces em um pacote é um indicador de extensibilidade do pacote.
  • Acoplamento Aferente: quantidade de outros pacotes que dependem de classes contidas em um determinado pacote é um indicador de responsabilidade do pacote.
  • Acoplamento Eferente: quantidade de outros pacotes dos quais as classes em um determinado pacote dependem é um indicador de independência do pacote.
  • Abstração: proporção de classes abstratas e interfaces em um pacote em relação ao total de classes nesse pacote. 0 indica um pacote concreto e 1 indica um pacote completamente abstrato.
  • Instabilidade: proporção entre o acoplamento eferente e o acoplamento total. Essa métrica é um indicador de resistência a mudanças do pacote. 0 indica que o pacote é estável e 1 indica que o pacote é completamente instável.
  • Distância da Seqüência Principal: indicador de balanço entre abstração e estabilidade em um pacote.
  • Complexidade Ciclomática: medida da complexidade de um método em relação a outro.

Análise Estática de Código

A SCA (Static Code Analysis ou Análise Estática de Código) é uma técnica que facilita a descoberta de anomalias ou erros de codificação existentes em uma aplicação. A forma mais básica e custosa de análise de código é a inspeção manual. Isso demanda tempo e alocação de pessoas. Portanto, devem-se utilizar ferramentas para automatizar o processo de SCA.

Ferramentas de Análise de Código

Existem muitas ferramentas para SCA. Cada ferramenta tem propósitos distintos, mas utilizadas em conjunto permitem uma análise mais completa do código. Analisamos as que seguem:

  • JUnit: possibilita testes unitários que dão informações a respeito do sucesso dos casos de teste.
  • Emma: mede e reporta a cobertura dos testes unitários.
  • PMD: procura e reporta problemas no código Java, como possíveis bugs, código não utilizado, expressões complexas e código duplicado.
  • Checkstyle: checa violações e auxilia a escrita de código que adere a padrões.
  • JDepend: verifica as métricas de qualidade para cada pacote de código do projeto a fim de medir a qualidade do design em termos de extensibilidade, reusabilidade e manutenabilidade para controlar as dependências entre os pacotes.

Avaliação de Ferramentas

Ferramentas de SCA podem ser integradas ao processo de desenvolvimento. Um servidor de integração contínua pode rodar o build da aplicação ao mesmo tempo em que o analisador de código é acionado. Dessa forma, podemos constatar problemas de código o mais rápido possível.

Também se pode dedicar tempo para procurar e resolver problemas de código de forma pontual. Para isso, pode-se, por exemplo, utilizar plugins de ferramentas de SCA para o IDE Eclipse.

Critérios para avaliação de ferramentas

Tabela 1 – Critérios para avaliação de ferramentas

A tabela acima mostra o critério que utilizei para avaliar algumas ferramentas de SCA. Como queria integrar a análise de código ao processo de build, precisava de ferramentas que tivessem integração com o Ant. Precisava também, se possível, de integração com o Maven. Hoje, utilizamos Ant como script de build para os projetos existentes, mas nos próximos projetos utilizaremos o Maven. A integração com o Eclipse – via plugins – não era impeditiva, mas era uma forma de fazermos rapidamente alguns testes com as ferramentas.

Juntando Tudo

Recentemente encontrei uma ferramenta que se propõe a ser um ponto central de gerenciamento da qualidade do código, o Sonar. Ainda não tive muito tempo para estudá-lo, mas já vi que ele ativa as engines de análise de código e exibe os relatórios produzidos pelo PMD e pelo Checkstyle.

Conclusão

Muitas pessoas tendem a achar que a raiz de todos os problemas é a baixa qualidade do código fonte. Essas pessoas também acham que LOC é uma medida eficaz de produtividade. Por isso, gastam tempo e dinheiro em ferramentas de análise de código. Controle de qualidade em nível de código muitas vezes nos dá a falsa impressão de que estamos garantindo a qualidade do produto, mas segundo Tom DeMarco:

Controle estrito é algo que importa muito para projetos inúteis e importa pouco para projetos úteis. Isso significa que quanto mais você foca em controle, maior a probabilidade de seu projeto estar entregando algo de valor baixo. (…) Desenvolvimento de software é e sempre será de alguma maneira experimental.

É importante não perder o foco na satisfação do cliente mediante a garantia da qualidade externa do produto entregue. Qualidade de código é desejável, mas código não é qualidade externa, ou seja, aquela que é vista por um usuário ou uma equipe de testes.

A análise de código apenas nos dá uma idéia dos problemas do código e da arquitetura da aplicação e nos fornece subsídios para avaliar se o estado atual do código compromete expansões planejadas para o sistema. Também nos indica o nível técnico da equipe de desenvolvimento e, de forma indireta, nos mostra o resultado da pressão dos prazos na qualidade interna do produto.

Analisar código mesmo com o uso de ferramentas não resolverá os problemas. Foco no código muitas vezes significa atacar o efeito e não a causa. Uma análise mais profunda de um problema pode remeter ao entendimento errôneo dos requisitos ou a existência de requisitos mal escritos. Análise de código é importante, mas é apenas a ponta do iceberg.

Fontes

Emma

http://emma.sourceforge.net/maven-emma-plugin/

JUnit

http://www.junit.org/

PMD

http://pmd.sourceforge.net/

Checkstyle

http://checkstyle.sourceforge.net/

JDepend

http://clarkware.com/software/JDepend.html

Sonar

http://sonar.codehaus.org/

Code Quality

http://jaibeermalik.wordpress.com/2009/04/12/code-quality-organizing-awareness-with-in-the-team/

Emergent Design Through Metrics

http://www.ibm.com/developerworks/java/library/j-eaed6/index.html

Software Engineering: An Idea Whose Time Has Come and Gone?

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

OO Design Quality Metrics

http://www.objectmentor.com/resources/articles/oodmetrc.pdf

Anúncios
  1. 05/01/2012 às 12:40 PM

    Achei um artigo bem interessante sobre medição de código:

    http://java.dzone.com/articles/measuring-code

  1. 17/02/2010 às 12:32 PM
  2. 09/01/2011 às 9:30 PM

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: