Refatoração, a maneira mais eficiente de manter seu código limpo.

Objetivo: O objetivo é mostrar o quanto é importante o processo de refatoração de código no dia a dia e porque devemos sempre que possível aplicar sua prática para manter o código longe o bastante de se tornar legado.

Inspiração: Esse artigo é inspirado em situações e dificuldades reais já vivenciadas em que a prática da refatoração sempre ajudou times a diminuir a complexidade do código.

Uma das skills que considero mais importantes em um desenvolvedor é a habilidade de entender a importância de sempre manter o código do time mais inteligível, melhorando assim a manutenibilidade, permitindo a execução do trabalho de maneira mais otimizada e consequentemente entregando mais valor para o cliente.

No livro “Refatoração: Aperfeiçoando o design de códigos existentes”, Martin Fowler nos mostra em seu prefácio como Kent Beck aumentou a eficácia de uma equipe de engenharia de software com a simples prática da reorganização contínua do código usando a refatoração.

Quando um projeto nasce, sempre fazemos o nosso melhor para que tudo seja claro e objetivo, definimos uma arquitetura, realizamos testes e deixamos o mais próximo do que achamos que seria a perfeição. Com o passar do tempo é inevitável que os requisitos mudem, com isso, o software muda, métodos que antes faziam uma coisa passam a fazer outra, outros nem são mais utilizados, novos bugs podem ocorrer e funcionalidades se misturam.

Se não lidarmos com a estrutura no início de uma alteração de requisito ou sempre considerarmos como um ‘debito técnico’ a falta de flexibilidade e o ‘ajuste técnico’ que foi necessário para incluirmos a nova funcionalidade, estaremos criando um pequeno monstro, que devorará todo o sistema em pouco tempo.

A prática da reorganização contínua do código nos permite sempre mantermos a casa organizada, ou seja, não é só incluir uma nova funcionalidade, mas sim pensar em como ela nasceu e o que fazer com a que já existia, dividir, remover, refatorar!. Diminuindo assim a degradação inevitável e permitindo que fique cada vez mais longe de se tornar um pesadelo (legado).

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — M. Fowler (1999)

O que é refatoração?

Refatoração é uma maneira disciplinada de reorganizar o código, melhorando sua estrutura interna sem alterar o comportamento externo, em poucas palavras, refatorar é realizar o aperfeiçoamento de um código já existente.

Refatoração exige cautela e deve ser feito de forma disciplinada e em pequenas porções para que não seja incluído novos bugs no sistema. A refatoração é uma técnica que deve ser praticada e sempre aprimorada.

Para realizar uma refatoração sempre devemos avaliar os testes que envolvem aquele trecho de código no qual foi escolhido, e se não existir, devemos criá-los para assegurar que o comportamento externo não seja alterado, assim como na prática de TDD, devemos seguir basicamente um ciclo: testar, refatorar, testar.

Os testes são sempre a garantia de uma boa refatoração e de um bom sistema, inclusive, a escrita de testes em um software quase sempre nos leva a alguma pequena refatoração.

Pense em seu sistema como uma grande pia, a cada nova funcionalidade, ajustes e correções incluímos um prato sujo nela! A refatoração é a bucha! se não lavarmos a louça a cada refeição (tarefa) só estaremos empilhando cada vez mais louça suja até chegar ao ponto de aparecer pequenos insetos (bugs).

Com a refatoração podemos partir de um design ruim, até mesmo caótico, e transformá-lo em um código bem estruturado.

Quando fazer?

“If it stinks, change it” — Grandma Beck, discussing child-rearing philosophy

Existem alguns ‘code smells’ que nos mostram claramente quando devemos iniciar um processo de refatoração, por exemplo, quando encontramos códigos duplicados espalhados pelo sistema, quando há métodos e classes muito grandes que evidentemente devem estar quebrando o princípio do SRP (Single Responsability Principle — SOLID).

Mas cuidado! não vamos sair refatorando tudo, nem todos os ‘smells’ indicam que você deve parar tudo para refatorar, é muito importante uma análise para realmente saber se aquilo é o problema em si, ou se há um problema subjacente.

Mas quando? Existem diversos momentos que podemos parar e pensar quando fazer:

• Ao adicionar uma nova funcionalidade: Sempre que vamos adicionar uma nova funcionalidade devemos pensar em refatoração. Refatorar nesse caso ajuda a entendermos melhor o sistema e compreender sua arquitetura. Além de manter a base da nova funcionalidade sempre limpa.
• Ao corrigir um Bug: Bugs são os melhores indicadores que precisamos de uma refatoração, normalmente o bug ocorre justamente por não termos compreendido o código em sua introdução, nesse caso a refatoração é muito importante para deixar o código mais claro (além de corrigir o bug).
• Code Review: Isso mesmo, quando estamos realizando um code review é muito importante o revisor olhar para o contexto como um todo e ver se aquela nova funcionalidade ou a correção de um bug não exige uma refatoração.

Uma das leis de Lehman diz sobre a complexidade crescente, em que se não forem tomadas medidas para reduzir ou mantê-la conforme o software é alterado sua complexidade irá aumentar progressivamente. Por isso, deve haver um esforço para reduzir a complexidade final de um sistema enquanto este recebe alterações.

A grande dificuldade nos times de desenvolvimento é tornar o ato da refatoração um hábito no processo contínuo do desenvolvimento, muitos desenvolvedores tem insegurança ao fazer uma refatoração, pensando que pode ser algo grande ou até mesmo que consuma muito tempo sem grande utilidade. Mas a verdade é que a refatoração está em pequenos detalhes e não deve ser algo grandioso (na maioria dos casos) e fora do escopo de sua tarefa, uma simples remoção de uma variável inutilizada, a alteração no nome de um método, a extração de trechos de códigos para outro lugar ou até mesmo a remoção de uma feature toggle que nunca mais será utilizada já é um processo de refatoração.

Apesar de ser contraditório o processo de refatoração contínuo acelera o processo de desenvolvimento, é como no exemplo de seu software ser uma pia, se lavarmos a louça regularmente, evitamos ter uma grande pilha de louça suja. Se refatorarmos o tempo todo, teremos um débito técnico muito baixo, o que implica que gastaremos tempo desenvolvendo software em vez de lançarmos tarefas somente para consertar problemas introduzidos por escolhas ruins no passado.

No livro Refatoração, Fowler deixa claro que a refatoração deve ser feita de forma contínua, em processos curtos, além disso o processo de refatoração não deve ser algo a ter um tempo determinado, pois não deveríamos decidir refatorar, mas sim ser o resultado de ter que fazer alguma tarefa. — Refatoração é um hábito.

“I’m not a great programmer; I’m just a good programmer with great habits.” — Kent Beck

Referências

• Refatoração: Aperfeiçoando o design de códigos existentes — Martin Fowler
• Trabalho Eficaz com Código Legado — Michael C. Feathers
• https://refactoring.guru/refactoring/course