Um estudo acadêmico recente levantou algumas questões sobre o quão útil e como é importante a refatoração.

Os pesquisadores descobriram que a refatoração não parecia tornar o código mais fácil de entender de forma mensurável as mudanças, ou mesmo de forma medida pela complexidade ciclomática, profundidade de herança, acoplamento de classe ou linhas de código.

Mas, como os desenvolvedores têm discutido, esse estudo é profundamente complexo. Ele parece ter sido desenhado por pessoas que não entendem como fazer refatoração corretamente:

1. Os pesquisadores escolheram 10 técnicas de refatoração de “grande impacto” (a partir de um estudo realizado em 2011 por Shatnawi e Li) com base em um modelo de qualidade de código orientado a objeto que mede a capacidade de reutilização, flexibilidade, capacidade de extensão e eficácia (“o grau que um projeto é capaz de atingir, os recursos desejados e seus comportamentos usando conceitos de design orientado a objeto e técnicas de desenvolvimento “- seja lá o que isso signifique), mas que especificamente não incluía compreensibilidade. E então descobriram que o código refatorado não mensurável foi mais fácil de entender ou corrigir. Isso foi uma surpresa? As refatorações tinham a intenção de tornar o código mais extensível, reutilizável e flexível. Em muitos casos, isso faria com que o código fosse menos simples e mais difícil de entender. Flexibilidade e capacidade de extensão e de reutilização muitas vezes vêm à custa de simplicidade, exigindo suporte extra e abstração adicional. Estes são investimentos de longo prazo que são pagos ao longo da vida de um sistema, algo que não poderia ser medido durante as horas que o estudo permitiu. A lista de técnicas não incluía refatorações comuns e, obviamente, úteis que teriam tornado o código mais simples e mais fácil de entender, como Extract Class e Extract Method (que são as duas refatorações de maior impacto, de acordo com uma pesquisa realizada pela Alshehri e Benedicenti de 2014), Extact Variable, Move Method, Change Method Signature, renomear qualquer coisa… [insira sua própria lista de outras refatorações úteis aqui].
2. Não há nenhuma evidência – e não há razão para acreditar – que o trabalho de refatoração foi feito, e feito corretamente. Presumivelmente, alguém inseriu alguns comandos de refatoração no Visual Studio, e o código foi “refeito corretamente”.
3. O estudo foi feito para medir se a refatoração tornou o código mais fácil de ser modificado. Mas eles tentaram avaliar se os alunos foram capazes de encontrar e corrigir erros que haviam sido inseridos propositalmente no código – o que mostra que o estudo é muito mais voltado para a compreensão do código do que para mudá-lo.
4. A base de código (4.500 linhas) e o tamanho do estudo (dois grupos de 10 alunos) foram ambos muito pequenos para serem significativos, e os alunos não tiveram tempo suficiente para fazer um trabalho perfeito: 5 minutos para ler o código, 30 minutos para responder a algumas perguntas sobre o assunto, 90 minutos para tentar encontrar e corrigir alguns bugs.
5. E, como apontam os pesquisadores, os desenvolvedores que estavam tentando entender o código eram inexperientes. Não ficou claro se eles teriam sido capazes de entender o código e trabalhar com ele, mesmo que isso tivesse sido feito corretamente.

Mas o estudo aponta para algumas limitações importantes para a refatoração e como ela precisa ser feita.

Uma boa refatoração leva tempo

Refatoração de código toma experiência e tempo do desenvolvedor. Tempo para entender o código. Tempo para entender quais refatorações devem ser utilizadas e em qual contexto. Tempo para aprender a usar as ferramentas de refatoração corretamente. Tempo para aprender o quanto a refatoração é suficiente. E tempo para começar a fazer o trabalho direito.

Alguém que não está familiarizado com a linguagem, o projeto ou o domínio do problema, e que não tenha trabalhado com refatoração antes, não vai fazer um bom trabalho.

Refatoração é algo egoísta

Quando refatorar um código, ele dirá tudo sobre você. Refatorar o código pode ser uma forma de tornar mais fácil de entender o que você pode querer mudar no futuro. Mas isso não significa necessariamente que o código será mais fácil para outra pessoa entender e mudar.

É difícil dar errado ao fazer uma refatoração prática. Mas as mudanças estruturais mais profundas e mais complexas, como a refatoração para padrões ou “refatoração de larga escala“, são mudanças que tornam alguns programadores felizes e também podem tornar o código mais difícil para outros programas compreenderem e trabalharem – especialmente se o trabalho só for feito em uma parte do código (o que muitas vezes acontece com o bem-intencionado e ambicioso canal raiz de refatoração).

No estudo, os pesquisadores pensaram que isso tornava o código melhor, tentando torná-lo mais extensível, reutilizável e flexível. Mas não levavam as necessidades dos desenvolvedores em consideração. E eles não seguiram a primeira diretriz da refatoração:

Comece sempre entendendo o que você realmente precisa refatorar. Se você não está tornando o código mais simples e mais fácil de entender, está fazendo errado.

Ironicamente, o que os desenvolvedores do estudo deveriam ter feito – com o código original, bem como com o “código refatorado” – era refatorá-lo em seu próprio ambiente primeiro, para que pudessem entender o funcionamento do código. Isso teria tornado as coisas mais interessantes e o estudo muito mais útil.

Refatoração funciona

Não há dúvida de que a refatoração – feita corretamente – vai tornar o código mais compreensível, mais sustentável e mais fácil de modificar. Mas é preciso fazer isso direito.

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2015/03/making-refactoring-work.html