Qualquer equipe responsável por construir um produto busca entregar ao cliente qualidade. Para equipes de desenvolvimento de software, o aumento da qualidade do que é produzido está intimamente ligado à mudanças no seu processo de desenvolvimento. Existem diversas técnicas que buscam auxiliar as equipes a atingir este objetivo e que podem ser incorporadas ao processo utilizado, como, por exemplo, a criação de testes automatizados, o uso de integração contínua, o TDD etc. Hoje falaremos de uma dessas técnicas, a refatoração.

Já conversamos sobre refatoração aqui no blog anteriormente. Em Débitos técnicos e a Refatoração, Rodrigo Aguas falou sobre como a refatoração nos ajuda a evitar o acúmulo de débitos técnicos e como esse acúmulo pode ser perigoso para o futuro do projeto. Depois disso, o post A importância da refatoração do Marcelo Areas nos mostrou que a refatoração tem por objetivo manter o código simples, claro e sem duplicações. Neste post, vamos colocar a mão na massa e falar um pouco sobre ferramentas que podem auxiliar o processo de refatoração de código dos nossos projetos.

Essas ferramentas são conhecidas como ferramentas de análise de código estático, ou seja, análise do código fonte de um programa sem precisar executá-lo. Dentre os objetivos desta técnica estão a verificação da estrutura do código em relação à estrutura padrão recomendada pela linguagem utilizada, a detecção de bugs e a realização de medições do software, como o cálculo das médias da complexidade ciclomática e da quantidade de linhas por método, por exemplo. Esse tipo de análise nos permite identificar pontos do código altamente suscetíveis a falhas, a problemas de performance, escritos de maneira não recomendada e que estão gritando por mudanças, ou seja, pontos que precisam ser refatorados.

Toda essa análise pode ser realizada por nós mesmos, manualmente. O problema é que nem sempre conseguimos escutar os gritos daqueles trechos de código. Às vezes a necessidade de refatoração não está clara para todos, às vezes estamos tão envolvidos no novo código que não damos a atenção necessária à refatoração dentro do nosso processo. Ou às vezes simplesmente não temos tempo. Quando a revisão de código passa a fazer parte do processo de desenvolvimento de uma equipe, há muito código ainda não revisado e nem sempre é possível fazer a equipe parar para analisar tudo o que já foi codificado. E aí está a grande vantagem do uso dessas ferramentas. Elas não dispensam a atividade manual e a revisão do código pelos desenvolvedores, mas elas nos ajudam imensamente por serem capazes de analisar todo o código existente e identificar maus cheiros muito mais rápido do que nós conseguiríamos.

Na Wikipédia, podemos encontrar uma lista dessas ferramentas, divididas por linguagem de programação. Como nos projetos em que trabalho utilizamos Java, as ferramentas que mostrarei para vocês neste post estão voltadas para esta linguagem. Todas as 3 ferramentas mostradas a seguir foram testadas por mim brevemente através de plugin para a IDE Eclipse e, após breve descrição de cada uma delas, passarei a vocês a impressão que tive do uso de tais ferramentas.

1. Checkstyle: esta ferramenta nasceu com o objetivo de analisar problemas de layout de código, como espaços indevidos, por exemplo, e a sua configuração default trata justamente disso. A partir de versão 3, ela incorporou em sua análise a busca por bugs, códigos duplicados etc e para fazer com que o plugin varra seu código atrás desses problemas é preciso criar uma configuração customizada indicando quais são os módulos que você deseja utilizar. Os problemas encontrados são apresentados na aba Problems do Eclipse e te mostram a linha do arquivo onde o problema foi encontrado e o que eles sugerem que seja feito para resolver a questão. Ela também possui um módulo de métricas e permite que você construa um módulo customizado de análise de código. 

2. FindBugs: esta ferramenta é bastante robusta e é mantida pela Universidade de Maryland. Ela classifica os problemas encontrados em diversas categorias, o que permite que o desenvolvedor foque inicialmente naqueles que parecem ser mais perigosos para o seu software, e permite selecionar quais detectores de bugs devem ser utilizados. Os problemas encontrados são apresentados em aba própria do plugin e apresentam o problema que pode acontecer no trecho de código examinado, em vez da sugestão de correção. Além disso, se clicarmos em cada um dos itens apresentados, ele apresenta uma breve descrição do bug encontrado detalhando por quê aquele uso é ruim para o código. Esta ferramenta é utilizada em grandes projetos, como o Java Server Faces.

3. CodePro AnalytiX: esta ferramenta é mantida pelo Google em parceria com o Eclipse Project e apresenta funcionalidades similares ao FindBugs. A diferença está no módulo de geração de casos de testes automatizados e no módulo de métricas, que permite a visualização de gráficos e a configuração de valores considerados limites para cada uma das métricas. Se esse limite é ultrapassado, no relatório a métrica é apresentada em vermelho para evidenciar o problema encontrado. Outro diferencial é que ela une aspectos das duas ferramentas anteriores em relação ao resultado apresentado: ela mostra o problema, por quê ele é ruim para o código e a sugestão de melhoria. 

Após utilizar as 3 ferramentas tive a impressão de que a última, a CodePro AnalytiX, é a que mais se encaixa nas necessidades de quem está incluindo a análise de código estático no seu processo de desenvolvimento. Apesar da FindBugs me parecer a mais robusta dentre as 3, a CodePro AnalytiX não fica atrás nos problemas encontrados e, para quem está começando, explicar por quê o código está ruim e sugerir a solução é muito importante. Isso faz com que, com o tempo, a equipe aprenda com aqueles erros e os evite no futuro. Além disso, em casos em que não se sabe o que fazer para resolver o problema, a própria ferramenta pode apontar a direção. Algumas pessoas recomendam o uso tanto da FindBugs quanto da CodePro AnalytiX. Eu acredito que, inicialmente, a CodePro AnalytiX é suficiente para levar a equipe para o caminho da refatoração, dando um apoio maior e fornecendo resultados mais claros e fáceis de serem compreendidos.

Como dito anteriormente, o uso dessas ferramentas não exclui a revisão manual do código. Até mesmo os erros encontrados automaticamente podem representar falsos problemas e devem ser analisados para decidirmos se devemos aplicar alguma correção ou não. O ideal é que essa análise passe a fazer parte do processo de desenvolvimento da equipe e a cada nova funcionalidade a preocupação de refatorar exista. Acredito que o uso de ferramentas de análise de código estático podem despertar essa preocupação na equipe e ser o pontapé inicial que estava faltando. E para aqueles que gostam do assunto não deixem de ler o livro “Refatoração – Aperfeiçoando o Projeto de Código Existente” de Martin Fowler.

E no seu projeto? Vocês utilizam este tipo de ferramenta? Conte sua experiência para nós.