Refatoração: quando fazer e quando não fazer

Quando pensamos em refatoração de código, por vezes imaginamos que o código precisa ser melhorado, ou ainda que ele não satisfaz condições para adicionar uma nova funcionalidade. Isso está correto, com muita frequência refatoramos códigos por esses motivos, mas precisamos identificar em que momentos devemos ou não refatorar.

Tipos de Refatorações

Alguns tipos de refatoração poderá nortear sua tomada decisão no momento em que se deparar com uma. Vamos ver quais tipos existem.

1° Refatoração preparatória

Ela geralmente acontece quando temos uma nova feature para desenvolvermos. Temos dois caminhos possíveis:

• “Piorar” o que já tem para poder incluir a nova feature
• Parar por um momento e fazer uma refatoração do código para deixar o código mais escalável e assim, conseguir adicionar seu novo código.

Esse tipo de refatoração é necessária, pois para mantermos um código mais limpo, organizado e aberto a novas funcionalidades, é sempre melhor refatorar.

2° Refatoração para compreensão

Sabe quando estamos lendo um código e não entendemos nada do que ele está fazendo? Ou até entendemos, mas demoramos mais tempo entendendo do que codando algo nele? Pois bem, esse é um ótimo momento para refatora-lo. Aquela máxima de escrever código para si próprio sem pensar no seu eu do futuro ou sem pensar em seus colegas de equipe, resulta em códigos de difícil compreensão. Quando se deparar com códigos assim, pense um pouco em como você gostaria de ter encontrado esse código, e refatore. Siga a regra do acampamento: sempre deixe o local onde estiver mais arrumado do que quando você chegou.

3° Refatoração para coleta de lixo

Esse é o caso de estarmos programando e então nos deparamos com códigos repetidos, funções que não estão fazendo nada, componentes repetidos para todo lado, e poderiam estar parametrizados. Outro caso de “sujeira” é aquele TODO que já se passaram 2 meses e ainda está lá, e o pior, ninguém mais lembra o que era pra ser feito. A todo momento nos deparamos com códigos que por algum motivo sujam o projeto, e nesse momento é necessário refatorar. Caso seja uma limpeza simples de código, faça no mesmo momento. Caso demande um pouco mais de tempo, termine a tarefa que está fazendo e ao final refatore essa outra parte de código. Se deixarmos nossa base de código um pouco melhor a cada vez que passamos por ele, com o tempo teremos código mais limpo e organizado.

4° Refatorações planejadas e oportunistas

Os exemplos apresentados anteriormente, são todos exemplos de refatorações oportunistas, ou seja, não reservamos um periodo de tempo, apenas vemos uma oportunidade de refatorar e o fazemos em conjunto com tarefas do dia a dia. Refatorações planejadas, são os famosos débitos técnicos. Sabemos que algo precisa ser refatorado, e criamos uma card de débito técnico para que em um futuro próximo, possamos refatorar aquele código. Porém, ao pensarmos em refatorações planejadas, podemos incorrer no erro de que tudo será para depois, pois o mais urgente é a entrega da tarefa, e isso é uma cilada. Refatorações planejadas em sua grande maioria deve ser evitada. Devemos nos concentrar ao máximo em fazermos refatorações oportunistas.

5° Refatoração de longo prazo

A grande maioria das refatorações, podemos fazer em questão de minutos ou em algumas horas. Porém, em alguns casos essas refatorações precisarão de mais tempo, em casos como: substituir uma lib existente no projeto, extrair um componente para ser reutilizado, ou ajustar dependências que estão gerando muita confusão no código. Você pode pensar: ah, para esses casos ter um equipe dedicada para isso, ou termos refatorações planejadas, seria a melhor abordagem. Pois bem, não é a melhor opção. O que seria mais eficiente, é fazermos refatorações de longo prazo, ou seja, trabalhar gradualmente nas refatorações. Por exemplo, para mudarmos uma biblioteca, podemos criar uma abstração no código para que funcione como uma interface para ambas as bibliotecas, e só após essa abstração conseguir funcionar bem tanto pra uma como pra outra, podemos então excluir a biblioteca antiga.

6° Refatoração em uma revisão de código

Uma prática muito comum nas equipes de desenvolvimento de software é o chamado code review , ótimo para disseminar conhecimentos em uma equipe de desenvolvimento. Aqui, os desenvolvedores enviam seus códigos para uma análise, onde outros devs verificam questões como: clean code, execução de código, melhoria na performance etc. Code review é um ótimo momento para refatorarmos código,quando sugerimos algumas mudanças no código, podemos refatorar para aplicar as mudanças sugeridas e deixar o código com maior coesão.

Quando não refatorar?

Aparentemente sempre devemos refatorar, porém isso não é uma verdade absoluta. Há casos em que mesmo observando uma função que precisa ser refatorada, não irei refatorar. Se não preciso entender esse pedaço de código (mesmo que confuso) para prosseguir com minha tarefa, então não refatoro. Outro momento que a refatoração pode não ajudar mas atrapalhar, é quando ainda não estamos maduros os suficiente para refatorarmos códigos muito complexos, que exige uma certa expertise para isso. Outro caso que pode ser peculiar é quando chegamos a conclusão de que refatorar já não vale mais a pena, e que será necessário criar o código do zero. Esse último é um caso muito complexo de se avaliar, portanto use com cautela.

Conclusão

Agora que sabemos os possíveis casos que podemos refatorar ou não, fica muito melhor de observarmos nossas aplicações no dia a dia e utilizarmos das oportunidades que surgem para melhorarmos o código. Lembre-se sempre da regra do acampamento, e sempre que possível deixe o código melhor do que quando você o encontrou.

Referência: Refactoring, Martin Fowler