Essa semana saiu mais uma edição da Revista MundoDotNet. Desta vez, pude dar minha contribuição com um artigo em que a idéia é relacionar "métricas de código" com "design de software".  Acho que ainda exploramos muito pouco dos benefícios que as métricas de código podem oferecer para o aumento nos níveis de qualidade do design de um software. Apesar de haver muitas ferramentas, raramente se vê alguém que efetivamente obtém alguma vantagem em utilizar as informações que elas geram.

De maneira geral, eu tento dar ali um caminho para se chegar a sintomas de problemas de design por meio da análise numérica de informações extraídas do código-fonte. Assim como um médico pode usar os números extraídos de exames - como números de plaquetas, ph, taxas de glicose e colesterol e outras centenas de índices possíveis - para diagnosticar doenças e prescrever tratamentos, desenvolvedores de software também podem. Um dos caminhos é saber como algumas medições revelam problemas no design. Obviamente que números não são suficientes para avaliar o design de um software. A avaliação subjetiva e humana sempre será necessária. Mas eles podem sim ser de grande ajuda nessa questão.

Quando falamos em "problemas de design", a primeira coisa que me vem a cabeça são os mau-cheiros de código que nos levam aos padrões de refatoração. Assim, o artigo tenta mostrar como podemos encontrar pontos de refatoração à partir de métricas coletadas no código-fonte. Além disso, há a questão de utilizar tal abordagem de modo sistêmico, criando assim alguns mecanismos de proteção contínua do design e abrindo espaço para a evolução do código de forma contínua.

Sei que muitos leitores desse blog não trabalham e também não conhecem a plataforma .Net. Mas, mesmo para eles, recomendo comprar de vez em quando a MundoDotNet (eu não trabalho com Java, mas estou sempre lendo a MundoJava). A MundoDotNet é uma revista que foca na plataforma, porém com uma boa ênfase em aspectos gerais sobre desenvolvimento (como design, arquitetura e técnicas de desenvolvimento), o que a faz ser atraente para qualquer um que leve desenvolvimento a sério.

No caso do meu artigo em específico, ele poderá ser lido e aproveitado por usuários de qualquer plataforma de desenvolvimento. Se quiser discutir sobre o artigo, é só deixar um comentário aqui ou me enviar um e-mail.

Boa Leitura! 


Posted by: alisson.vale
Posted on: 2/12/2008 at 7:40 PM
Tags: ,
Categories: Coding | Design
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (6) | Post RSSRSS comment feed
 
 

Comments (6) -

Andrik Albuquerque Brazil

Wednesday, February 27, 2008 11:53 AM

Andrik Albuquerque

Olá Alisson,

Acompanho seu blog a um bom tempo e vc está de parabéns. Achei muito interessante a matéria e gostaria de saber como vocês coletam e utilizam as métricas na Phidelis, coletam as métricas em cada build? Fazem o ciclo do TDD (teste falha, implementa, refatora) e coletam as métricas na refatoração ou algo parecido. Eu acompanho o blog do Shoes e ele escreveu um post recente sobre Gerenciamento de débitos, vocês fazem uma abordagem semelhante?

Abraço

alisson.vale Brazil

Wednesday, February 27, 2008 11:22 PM

alisson.vale

Andrik,

Obrigado por acompanhar o blog e que bom que o conteúdo está indo bem ;). Sobre a questão das métricas, hoje na empresa nós as coletamos em cada build usando o CCNet e o SourceMonitor. Infelizmente, as mais de 3500 classes do nosso produto dificultam muito o trabalho de análise sistemática das métricas. Mas o grande benefício é que os problemas de design realmente ficam escancarados à espera de uma solução. O simples fato de você ter certeza a respeito de onde estão os problemas já é um grande avanço pra nós.

Abraços,
Alisson

Wellington Mattos Carvalho Brazil

Saturday, March 15, 2008 9:45 PM

Wellington Mattos Carvalho

Alisson,

Tudo bem? Achei muito interessante o seu artigo mas infelizmente não consegui achar a revista nas bancas. Estou terminando uma monografia sobre arquitetura de software e realizando um estudo de caso comparativo entre duas arquiteturas,ja li diversos artigos no SEI (Software Engineering Institute) analisando o método SAAM e ATAM, só que queria utilizar métricas para analisar a qualidade do software e achei que seu artigo poderia ser útil para constar como referência.. só que não consigo encontrar a revista. Você pode repassar o artigo?

Att,

Wellington.

Clavius Tales Brazil

Tuesday, March 25, 2008 8:13 PM

Clavius Tales

Oi, Alisson.

Desculpe a demora em comentar esse "post", mas é que só agora li o artigo.

Simplesmente sensacional! Sem dúvida alguma, um dos melhores artigos que já li na vida sobre desenvolvimento de "software".

Parabéns, meu caro!

Um abraço.

Tales

alisson.vale Brazil

Wednesday, March 26, 2008 10:05 AM

alisson.vale

Oi Clavius,

São comentários como esse que nos fazem seguir adiante nessa empreitada de escrever e divulgar assuntos dessa natureza. Vindo de você então - uma das pessoas com maior sucesso na adoção do modelo ágil de trabalho - o elogio é ainda mais engrandecedor.

Muito obrigado mesmo.
Um grande abraço,
Alisson

Humberto Brazil

Friday, February 13, 2009 2:55 PM

Humberto

Ola,
Essa idéia é realmente interessante. Inclusive a microsoft disponibilizou gratuitamente as ferramentas FXCop e StyleCop.

O FXCop analisa o assembly compilado em busca de inconsistências no código tais insegurança, pouca performance, etc.
msdn.microsoft.com/en-us/library/bb429476.aspx

O StyleCop analisa o código-fonte em .NET e classifica o código por meio de regras envolvendo as categorias de documentação, layout, manutenibilidade, nomenclatura, legibilidade, etc.
http://blogs.msdn.com/sourceanalysis/

Inclusive é possível configurar se uma determinada violação no código consiste num erro ou apenas num aviso para o programador.
Assim , além de gerar estatísticas, você também poderá de certa maneira prevenir erros no código.

Pingbacks and trackbacks (2)+

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading