Identificando Oportunidades de Refatoração através de Métricas

Estava lendo o excelente artigo Medindo a complexidade do seu código no blog da Caelum e resolvi tirar da gaveta o artigo que fiz para a conclusão da Pós que fiz em Engenharia de Software + Métodos Ágeis em 2010/2011.

Por falta de tempo, aprofundei menos do que gostaria na pesquisa.

Se alguém quiser colaborar no estudo da relação entre métricas e refatorações, me dá um toque!

Segue o resumo do artigo:

A prática de refatoração é uma maneira efetiva de realizar a melhoria contínua do código fonte de um software, de maneira a permitir que mudanças nas necessidades de negócio dos clientes sejam implementadas com menos esforço.

Porém, a detecção de qual código deve ser refatorado depende muitas vezes da intuição de
especialistas.

Este artigo estuda o uso de métricas de código fonte na identificação de oportunidades de refatoração, de maneira a detectar pontos de melhoria de maneira quantitativa.

Foi realizado um estudo de caso de dois projetos comerciais em que métricas de código fonte foram levantadas e analisadas, de maneira a identificar pontos de melhoria e relacioná-los a possíveis refatorações.

Os resultados mostram o uso de métricas como uma ferramenta interessante para identificação de possíveis refatorações em uma base de código.

Porém, como uma mesma métrica pode estar relacionada a várias refatorações, a decisão de qual refatoração deve ser
efetuada ainda depende de intuição.

 

 

PDF para download:

Identificando Oportunidades de Refatoração através de Métricas

 

 

TDD by Kent Beck

Acabei de assistir o vídeo de TDD que o Kent Beck gravou para os Pragmatic Programmers. Pra quem não conhece, o cara é a mente brilhante por trás de XP, TDD e Design Patterns.

No vídeo, Kent implementa um wrapper em Java para o Tokyo Tyrant, um servidor de banco de dados bem leve que serve como uma hashtable remota de bytes. O exemplo é inusitado.

Não há nada muito novo pra quem pratica TDD e/ou já leu o livro do mesmo Kent Beck sobre o assunto, o TDD by Example.

Uma idéia interessante é fazer Scaffolding Tests, algo como “Testes Andaime” em português. São testes que servem de suporte para você implementar uma funcionalidade e que, a princípio, expõe uma implementação interna da classe que você está desenvolvendo.  À medida que você avança na implementação, pode esconder essas implementações internas em métodos privados e remover os testes correspondentes. Os testes da API pública da classe já exercitarão esses métodos privados. Quem tem um pouco de experiência com TDD, acaba fazendo frequentemente.

Outra ideia legal é o que ele chama de TDD Games: brincar com a ordem das suas decisões de design, apagando código e seguindo novos rumos, pra aprender o efeito das decisões no rumo do design.

Kent chama a atenção para o fato de todo teste implementado é um custo a mais no projeto e cada teste não implementado é um potencial risco. Ao praticar TDD, é importante balancear entre esses dois fatores: custo x risco.

Para Kent Beck, cada teste deve ser uma pequena estória, com início, meio e fim. Tanto no nível da história, como de uma funcionalidade ou de um sistema, é mantido um ritmo semelhante:  definição do problema, desenvolvimento e limpeza do código. Esse ciclo se repete em vários níveis, desde minutos para implementar um história, como dias para implementar uma funcionalidade e semanas para implementar um sistema (ou sub-sistema). A limpeza do código serve como um fechamento do ciclo. É fácil saber quando você acabou uma etapa e o código se mantém limpo.

Assim, é atingido o objetivo: código limpo e que funciona.

Agilidade != Velocidade

Ser ágil é ter facilidade de mudar de direção.

 

Do excelente texto de Juan Bernabó:

Ser ágil não se trata de velocidade, se trata sobre ser enxuto. Ou seja imagina algo que tem muita massa, pode ganhar extrema velocidade e ser muito rápido, porem terá muita inercia e terá dificuldade de mudar de direção.

Para poder ser ágil e flexível será necessário abaixar a massa, e isto a gente faz em Scrum usando o conceito de One Piece Flow (criar um fluxo de produção de uma única peça) por exemplo se faz fluir um único requisito funcional desde o detalhamento ate o teste funcional no menor tempo possível, fazendo que toda a equipe se concentre na menor quantidade possível para abaixar o estoque de trabalho em progresso (um conceito de Lean – Toyota – Just in Time) para poder responder a mudanças sem stresse.

Daqui.

Caracteres inválidos no seeds.rb

Ao executar o db:seed para fazer uma carga inicial de dados no Rails 3.0.5, rodando com o Ruby 1.9.2 no RVM, obtive o seguinte erro:


invalid multibyte char (US-ASCII)

O problema era que, no meu arquivo seeds.rb, havia Strings com caracteres inválidos para o encoding ASCII padrão. Por exemplo:


Genre.create(:name => "Ação")

Para resolver isso, basta inserir na primeira linha do seeds.rb o seguinte comentário:


# encoding: UTF-8

Parece que é um problema do método load do Ruby.

____________

Uma referência básica sobre encoding é o artigo The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), do Joel Spolsky.