Boas práticas de Refactoring

A técnica de Refactoring definida segundo Martin Fowler, se baseia em reestruturar um trecho de código para melhorar sua estrutura interna sem alterar seu comportamento externo.

Várias práticas podem ser utilizadas para refatorarmos nosso código fonte, essas práticas são fundamentadas em princípios. Vamos abordar alguns dos princípios básicos:

Express your intentions
Devemos sempre lembrar que o código que escrevemos será lido por outras pessoas ou por nós mesmos meses ou anos depois. Portanto, é importante atribuirmos nomes sugestivos e claros para os componentes do nosso sistema.
Variáveis e procedimentos com nomes que não nos remetem exatamente pra que nos servem devem ser substituídos por nomes mais adequados que explicitam seu significado.

Single Responsibility
Robert C. Martin define que toda unidade de software, seja ela uma função, método ou classe deve possuir uma única responsabilidade e deve ter somente uma razão para mudar. Esse princípio chamado de Single Responsibility (Responsabilidade Única) consiste em extrair os comportamentos de uma unidade em outras unidades, diminuindo a complexidade de cada uma delas e facilitando sua compreensão e legibilidade, resultando consequentemente em um código muito mais fácil de se manter.

Don’t Repeat Yourself
Cada nova linha de código criada tem um custo, quanto mais linhas de códigos são criadas, maior será o custo de tempo e esforço gerado em torno desse código. Mais código existente significa mais código pra ser lido, entendido e mantido. Portanto devemos considerar a possibilidade de reaproveitar todo comportamento já existente e criar apenas o que for realmente necessário, evitando duplicar componentes.
O princípio DRY (Don’t Repeat Yourself – Não se Repita) afirma que cada parte de conhecimento do sistema deve ter uma representação única e não ambígua, garantindo que uma possível mudança em um elemento não necessitará de uma mudança em outros pelo mesmo motivo.

Assim, quando este comportamento mudar, e ele provavelmente irá, será necessário a alteração em apenas um local que automaticamente todos os outros locais que utilizam desse comportamento acompanharão a mudança.

Magic Numbers
É comum encontrarmos valores fixados em várias partes do código que dificultam sua compreensão por não serem claros o suficiente quanto ao seu significado causando um esforço de investigação desnecessário.
Todo esse esforço pode ser minimizado ao atribuirmos o valor desejado a uma constante declarada com um nome autoexplicativo e substituindo as ocorrências dos valores pela constante. Desse modo, em todas essas ocorrências ficará claro e sugestivo o significado do valor independente do contexto aplicado.
Outra vantagem dessa prática, é que em uma futura alteração desse valor, poderemos alterar somente a atribuição da constante não exigindo a necessidade de percorrer todas suas ocorrências para realizar a mudança.

É interessante lembrarmos que a técnica de refatoração pode ser melhor aplicada, se o projeto contar com uma boa cobertura de testes automáticos, assim saberemos rapidamente se as mudanças na estrutura do código afetaram outros comportamentos inesperadamente.

Referências
[1] https://pt.wikipedia.org/wiki/Refatora%C3%A7%C3%A3o
[2] https://pt.wikipedia.org/wiki/Don%27t_repeat_yourself
[3] https://en.wikipedia.org/wiki/Single_responsibility_principle

Por JOÃO PAULO GRABOSQUE

Graduado em Engenharia de Software, Materano apaixonado pelo que faz, atua como Agilista com foco em Scrum e Kanban.

Postado em: 10 de outubro de 2016

Confira outros artigos do nosso blog

Inteligência Artificial: uma introdução ao Deep Learning

11 de setembro de 2018

Guilherme Moraes Armigliatto

Implementando Circuit Breaker com Spring Cloud Netflix

25 de julho de 2018

Jamila Peripolli Souza

Balanceamento de carga em microsserviços com Spring Cloud Netflix

13 de julho de 2018

Jamila Peripolli Souza

Quais os benefícios da arquitetura REST?

26 de junho de 2018

Henrique Lacerda

Deixe seu comentário