🇧🇷 Refactoring: Não o subestime

Eu gostaria de iniciar esse post colocando a seguinte sentença que aprendi: Não tenha medo de refatorar.

O motivo que estou escrevendo esse post é pelo fato de que recentemente li o livro do Martin Fowler: Refactoring — Improving the design of existing code. Recomendo muito pois mudou minha forma de enxergar o assunto.

Vou descrever abaixo alguns pontos que foram importante quando refleti sobre a forma como codifico. Não é fácil ter a auto-disciplina de aplicar a proposta, especialmente se a sua forma de codificar é diferente, mas vale a pena.

O que é refactoring e porque fazê-lo?

Refactoring é o processo de mudança de software de maneira que o comportamento externo não é alterado, mas sim a sua estrutura interna.
- Martin Fowler (1999)

É uma tentativa constante de escrever código menos propenso a erros e um aperfeiçoamento do design após sua escrita.

Quando você olha para engenheiros civis, por exemplo, eles sabem com antecedência como prédios precisam ser construídos, pois existem regras e leis que os guiam ao prever os melhores recursos para o projeto.

A história é diferente com engenharia de software, pois processos de negócio são projetos dinâmicos que tendem a mudar baseado em vários fatores que não seguem regras ou leis imutáveis.

Dado um negócio que está sempre crescendo e mudando, quando refactoring não é aplicado, então o código existente tende a se tornar uma ferramente de hacking para atender o negócio. Isso irá diminuir a sua performance e de seus colegas ao achar bugs, prever esforço necessário para uma funcionalidade e eventualmente parar de atender às necessidades do negócio em tempo hábil.

Por outro lado, ao aplicar o refactoring você ganha o benefício de ler o código e entender o que está acontecendo. Dessa forma o fix do bug se torna claro ou a funcionalidade nova tem um lugar mais claro para ser criada.

Testes

Os testes serão o seu primeiro aliado nesse assunto e também aumentam a qualidade do software.

O motivo pelo qual tinha medo de refatorar é que a mudança de código existente, que funciona, pode levar a novos bugs no código. Mas se você tem uma boa base de teste em primeiro lugar, eles sempre estarão lá garantindo que o resultado esperado ainda acontece. Você também gasta menos tempo debugando o software.

Tendo dito isso, em primeiro lugar, escreva os testes antes de mexer no código fonte ao consertar um bug ou criar uma feature.

Refatore

Existem várias maneiras de refatorar, que não serão descritas nesse artigo, mas se você basicamente procurar por code smells e aplicar algumas técnicas de refactoring, você estará em uma melhor situação e ajudará o próximo desenvolvedor que tocar nesse código.

A regra básica seria: Sempre deixe o acampamento melhor do que você encontrou.

Compile e rode os testes

A cada passo no processo de refactoring, faça o build e rode os testes. Dessa maneira você encontra mais cedo quando comente um erro — somos humanos e errar é normal.

Você encontrará ferramentas que realmente ajudam nesse trabalho. Um bom exemplo é o Visual Studio com a funcionalidade de Live Unit Testing.

Resumindo

Se você aplicar o processo constante de escrever testes, refatorar, compilar e rodar os testes, como desenvolvedor você verá uma melhora na sua performance, a forma como codifica irá mudar para melhor e você irá começar a pensar no próximo desenvolvedor que tocar nesse código.

Questões em sua cabeça começarão a aparecer: Se alguém ver esse código, é possível entendê-lo? Esse nome está de acordo com a língua usada no meu domínio? O nome dessa variável tem sentido? É possível relacionar o código com os critérios de aceitação ao ler o código?

Com esse modo de pensar, eu acredito que a famosa frase foi formada:

Qualquer um pode escrever código que um computador é capaz de entender. Bons programadores escrevem códigos que humanos podem entender.
- Martin Fowler (1999)

Em essência, seja razoável e pense no próximo que você irá codificar melhor.

Quais são as suas experiências com isso? Você tem algo para compartilhar? Deixe um comentário ou me siga no Twitter @_arleypadua.

Este artigo também está disponível em Inglês.