Refatoração 101 — 5 Passos Para Um Código Mais Limpo

A refatoração é o processo de mudar a estrutura do seu código sem mudar o modo como o programa se comporta. Apesar de ser importante, não é tão trivial quanto parece: reorganizar código e mantê-lo coerente pode se tornar uma tarefa trabalhosa dependendo do tamanho do projeto. É sempre legal separar esse processo em algumas micro-tarefas, e nesse post, eu quero compartilhar 5 delas que podem te ajudar a escrever código muito mais limpo:

#0 — Mindset De Refatoração

Até antes da lista começar, um ponto até certo ponto polêmico: Refatoração deve ser parte inerente, não apenas um card que aparece em todo sprint ou que vive eternamente no seu quadro Kanban. O problema com isso é que a refatoração é o que chamamos de housekeeping: manter a casa em ordem.

Qualquer profissão, não somente a de desenvolvedor, necessita de housekeeping. Um carpinteiro, por exemplo, não cobra a mais para limpar as serragens do chão de sua oficina ou para lixar o móvel que preparou antes de entregá-lo ao cliente. Essas tarefas até podem ser adiadas, mas inevitavelmente serão feitas por serem parte do trabalho. Como um(a) desenvolvedor(a), é essencial que, ao iniciar ou finalizar algo, seu trabalho seja analisado, polido, melhorado: Na verdade é necessário ir além disso. É necessário que durante o desenvolvimento sua mente esteja buscando melhoramento contínuo! :)

#1 — Escreva Testes!

De longe essa é a estratégia mais fácil pra evitar seu telefone tocando as 7h da manhã de domingo dizendo que o sistema inteiro explodiu por causa do seu deploy da sexta-feira.

Sem qualquer tipo de testes fica muito mais difícil assegurar que o código continua funcionando da mesma maneira, mesmo com mudanças estruturais. Testes podem te oferecer a segurança necessária de saber que suas mudanças não quebraram a aplicação de alguma maneira obscura e inesperada. Testes são seus amigos, e criar bons testes é um investimento no seu processo de refatoração!

#2 — Defina Responsabilidades

Não, eu não estou falando de delegar tarefas pro Júnior da Equipe. Estou falando de um conceito já antigo, comentado desde a década de 70, que foi popularizado pelo ‘Uncle Bob Martin’ e os seus princípios SOLID do design orientado a objeto: O princípio da responsabilidade única.

“Uma classe deve ter apenas uma razão para mudar”

Abrangendo não apenas OO podemos expandir essa definição pra, além de classes, ser aplicada também a abstrações de métodos:

Um método ou classe deve fazer apenas uma coisa (uma responsabilidade).

Por que é importante separar responsabilidades? Reusabilidade, “debuggabilidade”, abstrações mais simples, testabilidade, etc.

No entanto é bom lembrar que é fácil exagerar na hora de desacoplar código.
Como dica, cheque se suas mudanças:

1. Melhoram legibilidade;
2. Encapsulam lógica não relacionada diretamente ao método (baseado no nome);
3. Tornam o código ‘auto-documentável’;
4. Melhoram reusabilidade;
5. Tornam testes mais fáceis;

Caso sua mudança não satisfaça nenhum dos itens da lista acima, é possível que esteja exagerando :)

#3 — DÊ BONS NOMES A MÉTODOS/CLASSES

Não consigo enfatizar mais que isso. É de longe o ponto mais fácil de ser ignorado e talvez um dos de maior impacto. Sabe aquelas variáveis str ou num ? Mate com fogo. Uma variável armazena dados, então nomeie-as de acordo. Uma variável isActive é muito mais fácil de entender que uma on!

A mesma regra se aplica para métodos — métodos são para o código como verbos são para um texto. Dê nomes curtos, descritivos e que expliquem o que está sendo feito e não como. checkIfHasPhoneCharacters pode se tornar um isValidPhone , por exemplo.

Como conteúdo muito bom nesse assunto, recomendo esse vídeo sobre a importância dos nomes do Filipe Deschamps (também conhecido pelos amigos como o Dev mais lindo desse Brasil).

#4 — Remova (E Não Crie!) Código Morto

Escolha qualquer codebase aí. Eu tenho total certeza que vai ter alguma parte do código comentada ou não utilizada com um // TODO: Refatorar. Alguém passou, substituiu uma implementação por outra e comentou a parte antiga — simples, rápido e efetivo, não?

Na verdade o código morto é altamente efetivo em uma coisa: espalhar medo, incerteza e dúvida. A máquina irá se livrar desses comentários em frações de segundos, mas e a pessoa que herdará essa codebase? Código morto, não utilizado, perdido em comentários, gera dúvidas como: “Por que foi removido? Por que foi deixado aqui? Será que ainda serve pra algo? Devo remover ou não?”.

Novamente, regra básica: remova e não deixe código morto pra trás. Uma boa ferramenta de versionamento (Git, Hg, …) te dará acesso ao código antigo caso necessário e você evita adicionar esforço mental para entendimento do código.

#5— Documente O Código

Todo mundo adora projetos, principalmente os Open Source, bem documentados. No entanto, poucos(as) desenvolvedores(as) se preocupam com boa documentação. Sim, a conta não fecha.

Apesar de ser um processo muitas vezes tedioso, é muito importante que algum tipo de documentação seja adicionada ao projeto. Seja usando assinaturas de tipos, comentários simples explicando o porquê de algo, ou mesmo comentários estruturados (como Rdoc, JSDoc, etc.), use parte do seu tempo para criar um código mais ‘acessível’ para outros desenvolvedores (ou pra você mesmo, só que no futuro!). Além de tudo, ao utilizar comentários estruturados, você ganha mais facilidade para desenvolver na maioria dos editores e IDEs, o que é um grande bônus por si só!

Concluindo…

Ainda existe uma quantidade enorme de técnicas e estratégias pra refatoração que não abordei aqui, mas o ponto chave é: Refatoração deve ser um processo contínuo e que demanda disciplina, mas é um investimento que se paga de diversas formas no processo do desenvolvimento.

E você? Quais as suas técnicas ninja para refatoração?

Um abraço, até a próxima!

Se você gostou desse conteúdo, deixe várias 👏 ali embaixo! Me siga aqui no Medium e no Twitter (@joaolucasluc) para acompanhar meus conteúdos futuros (e não deixe de me mandar feedback!)