Zona .Net

Refatorando idéias, produzindo conhecimento.

Qualidade de Código – Parte I

leave a comment »

Quem me conhece sabe que costumo escrever muito, especialmente quando o assunto é amplo e controverso. O convite para o blog surgiu no momento em que me aprofundo nesse intricado tema e pretendo, portanto, resumir nesta série de poucos posts, as experiências que tenho vivenciado nos últimos tempos.

Construir software de qualidade ainda é um desafio para as organizações. Seja pela premência do tempo, pela falta de maturidade ou mesmo pela simples falta de informação, muitas sequer inserem no seu processo de desenvolvimento, disciplinas que envolvam a aferição, testes e revisão do código fonte produzido.

Há um mito no estudo da qualidade que diz:

  Criar programas é uma arte que não pode seguir regras, normas ou padrões.

Removendo os absurdos, quantos de nós já não vivenciaram situações próximas a estas, especialmente às 23:00h do dia anterior ao prazo de entrega daquele projeto inadiável?

Não é meu objetivo aqui debater o extenso tema da qualidade, mas situá-la no âmbito das falhas inerentes ao elemento humano envolvido na elaboração de programas fontes[i] e nas alternativas automatizadas de aferição e testes recorrentes, com vistas a maximizar a produção de aplicações mais estáveis.

Quando se fala em aferir o código produzido, temos essencialmente três vertentes:

  1. Análise de métricas de código fonte (Code Metrics);
  2. Análise de conformidade a padrões de codificação (Static Rule Analysis);
  3. Análise manual do código fonte com base em listas de verificação (Checklists).

Destes métodos o meu preferido é de longe a análise de métricas. Digo isto porque as métricas de código fonte são baseadas em modelos matemáticos consagrados, em grande parte fruto de inferências da inspeção manual de código, amplamente pacificadas em ferramentas de mercado, algumas delas com décadas de existência.

Estes números são capazes de fornecer indícios importantes sobre a qualidade relativa do código fonte e, quando aplicadas durante o ciclo de desenvolvimento de um projeto, são capazes de revelar distorções antes vistas apenas nas etapas de testes integrados. 

Para exemplificar, vamos responder as seguintes perguntas:

  1. Ao analisar o código em uma classe o que lhe faria dizer se este ou aquele método é mais complexo?
  2. Qual critério você utilizaria para dizer que este ou aquele método está mais sujeito a falhar?
  3. Qual dos métodos é mais difícil de manter?

À minha mente vem imediatamente uma resposta para as três perguntas: “Ora, o método que possui mais linhas de código é o código mais complexo, mais propenso a falhas e mais difícil de manter.”

É nesta linha que nascem as métricas de código fonte. No exemplo acima a métrica é denominada SLOC (Source Lines Of Code).

Eu diria que na mesma proporção de complexidade dos sistemas atuais nasceram métricas e modelos matemáticos para atestar a exequibilidade, estabilidade, manutenibilidade e performance do código fonte gerado. Não vamos (e nem conseguiríamos) esgotar aqui todos estes elementos. Prefiro apresentar algumas métricas elementares, práticas e de grande valia.

Complexidade Máxima (CC): Originalmente denominada Cyclomatic Complexity, mede o nível de complexidade de um método/função. Elaborada por Thomas J. McCabe em 1976[ii] e aperfeiçoada por Steve McConnell da Microsoft em seu livro Code Complete de 1993.

A métrica CC mede o nível de complexidade através da contagem dos caminhos de execução distintos de um trecho de código. Cada método/função possui originalmente um CC igual a 1. Este valor é incrementado a cada instrução IF, ELSE, FOR, FOREACH, WHILE, TRY, CATCH encontrada. Estudos demonstram[iii] que trechos de código com CC superior a 25 possuem alto risco de conterem defeitos (>30%). Com CC superior a 60 a probabilidade cresce para 85% e a partir de 74 pontos, o risco vira fato.

Profundidade Máxima (NBD): Número máximo de blocos de código aninhados (Nested Block Depth) em um método ou função. Esta é outro forte indicativo da complexidade de um trecho de código. Estruturas de código IF, ELSE, FOR, FOREACH, WHILE aninhadas em excesso, além de tornarem a execução mais complexa, dificultam a compreensão e a legibilidade. Métodos/funções com NBD acima de 6 denotam necessidade de refatoramento.

Quantidade de Métodos Por Classe (MPC): Oferece um forte indicativo do grau de coesão de uma classe/library. Classes com muitos métodos apresentam uma forte probabilidade de acumularem mais responsabilidades que o necessário, violando o princípio da responsabilidade única (Single Responsiblity Principle).

Média de Instruções por Método (ASM): É uma derivação da métrica SLOC e mede a quantidade de instruções contidas nos métodos das classes, oferecendo claramente uma dimensão do seu tamanho.

Nível de Documentação do Código (PDOC): Mede a proporção de linhas que contém documentação (XML-DOC) em relação ao total de linhas de código num método, classe ou projeto. A proporção ideal situa-se entre 12% e 20%.

Nível de Comentários do Código (PCOM): Mede a proporção de comentários in-line em relação ao total de linhas de código num método, classe ou projeto. Idealmente, uma medida de 20% denota que o código está bem comentado. Códigos com proporção inferior a 5% e superior a 40% estão, respectivamente, pouco e muito comentados.

No próximo post, apresentarei ferramentas para coleta destas métricas e também exemplos de análise de código fonte. Até breve!


[i] Wohlin, C., Shull, F., Aurum, A., Ciolkowski, M., Petersson, M. (2002) “Software inspection benchmarking-a qualitative and quantitative comparative opportunity”. In: Software Metrics, 2002. Proceedings. Eighth IEEE Symposium, p. 118-127

[ii] McCabe (December 1976). “A Complexity Measure”. IEEE Transactions on Software Engineering: p. 308-320. http://classes.cecs.ucf.edu/eel6883/berrios/notes/Paper%204%20(Complexity%20Measure).pdf. 

[iii] Rich Sharpe. “McCabe Cyclomatic Complexity: the proof in the pudding”. Enerjy. http://www.enerjy.com/blog/?p=198.

Anúncios

Written by Gustavo Hurtado

18 de agosto de 2009 às 2:00 am

Publicado em .NET, Design Pattern

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: