Técnicas de refatoração e code smells
Contexto
Salve galera, hoje vamos falar um pouco de técnicas de refatoração de código e de quebra ainda vai rolar algumas dicas e boas práticas.
Atualmente estou fazendo o curso de “clean code and clean architecture” do monstro Rodrigo Branas e só na primeira aula ja temos uma baita visão de como funciona o processo de refatoração de códigos ruim e com ruim quero dizer, aquele código que todo mundo do trampo tem medo de mexer só de ouvir o nome a internet ja cai kkkk.
Então chega de enrolação e let’s bora 🔥
Começo por onde ?
Quando pegamos um código meio esquisito a primeira coisa que vem na mente é, por onde eu começo a mexer nesse troço, bom antes de mexer no código é muitoooo recomendado que você entenda o que é esse troço, “Ah, vá Mister Óbvio”, pior que é serio antes de fazer qualquer coisa o recomendado é sentar e entender o que esse código faz, chame alguém que já tenha mexido e que posso dar uma luz.
E uma maneira bacanuda de entender o código é por meio de testes automatizados, por exemplo testes unitarios, os testes além de garantir a qualidade do código e da aplicação também serve como uma boa documentação, então antes de mexer pare, pense, respire e crie alguns testes, vai ajudar muito.
Code smells, o que é isso??
Bom “Na programação de computadores, um cheiro de código é qualquer característica no código-fonte de um programa que possivelmente indica um problema mais profundo.”
Isso de acordo com a wikipedia, e sim estou usando a wikipedia para citar referencias técnicas, se fiz isso até no meu TCC por que não faria aqui só não conta para o meu orientador rs.
Na real minha visão de code smell e de boa parte da galera é definida em boas práticas ou acordos para manter um código saudável, legível e com uma boa munuteção.
Então vou passar por alguns passos que fazem sentido de se pensar na hora de refatorar um código ruim.
Só para deixar claro, o código que você vê como ruim hoje pode não ser ruim para outras pessoas ou pode não ter sido ruim alguns anos atrás, da mesma forma que um código refatorado hoje pode não ser bom ou saudável daqui 5 anos, então antes de aceitar regras como bala de prata, respire e lembre-se que trabalhamos com humanos antes de maquinas e somos pessoas antes de programadores e não queremos ferir o sentimentos de ninguem certo.
#Paz !!!
Nomes estranhos
Para começar, devemos renomear os nomes estranhos e que não deixam claro para o que estão sendo usados como, variáveis, métodos e classes é uma boa prática.
if (x === 1) return true
Olhando assim ninguém entende nada o que isso faz, o que é x? o que é 1 ? sei lá pode ser qualquer coisa, agora se renomear para algo que faça sentido.
if (diaDaSemana === 1) return true
Opa, ainda ta ruim, mas ja ficou mais claro de saber onde o código quer chegar.
Números mágicos
Continuando o exemplo acima, extrair números para algo com mais significado ajuda muito na leitura do código, por exemplo o que é 1 na condição, domingo?, segunda?, sabado?
const DOMINGO = 1
if (diaDaSemana === DOMINGO) return true
Pô agora ta claro, se dia da semana for igual a 1 então é domingo, pode parecer bobo mas olha a diferença de clareza que conseguimos transmitir.
Comentários
Excluir comentários desnecessarios que ouver.
Comentários são utilizados para explicar algo que você não conseguiu deixar claro no código, e podem sim ser usados mas com bastante cautela, por que tendem a poluir muito o seu código.
const DOMINGO= 1
// Verifica se dia da semana é domingo
if (diaDaSemana === DOMINGO) return true
Na minha visão este comentario é desnecessario. ❌
Código morto
Remover o maximo possivel de código morto, se ta morto, ta morto. Por que nada te garante que você irá usar aquilo, e não, você não pode ser colecionador de código morto, no máximo o que pode acontecer é te convidarem para o programa Acumuladores kkk, ok acho que não chega a tanto, mas para melhorar a leitura e garantir uma melhor cobertura de código remova linhas desnecessarias, como já dizia o famoso Jhow “Se não ta ajudando, ta atrapalhando”.
const DOMINGO= 1
if (diaDaSemana === DOMINGO) return true
Removemos o comentario do exemplo, mas também pode ser considerado código morto:
- Bloco de códigos comentados.
- Comentários sem agregar em nada.
- If ou else que nunca serão executados.
- Funções ou métodos que só estão lá para serem colecionados, igual eu coleciono funko pop.
Condições confusas ou o famoso Hadoukeeen !!!
Primeiro vamos dar uma olhada nesse código
if (diaDaSemana === DOMINGO) {
return 'dom'
} else if (diaDaSemana === SEGUNDA) {
return 'seg'
} else if (diaDaSemana === TERCA) {
return 'ter'
}
Voltamos as estranhesas rs, esse codigo está com muitas condições aninhadas e confusas que poderiam ser simplificadas por cláusulas de guarda, isso é eliminar o else retornando o valor simplificado.
if (diaDaSemana === DOMINGO) return 'dom'
if (diaDaSemana === SEGUNDA) return 'seg'
if (diaDaSemana === TERCA) return 'ter'
Tambem podemos simplificar condições com operadores ternarios:
Antes
if (diaDaSemana === DOMINGO) {
return true
} else {
return false
}
Depois
return diaDaSemana === DOMINGO ? true : false
O importante aqui é ter uma boa ideia do que a condição faz e mesmo assim ter uma legibilidade bacana.
Conclusão
Bom galera acho que para esse post é isso, vou tentar trazer uma parte 2 falando mais sobre esses assuntos porém sem deixar o conteúdo muito extenso, algo mais solto como gosto de fazer, obrigado para quem leu até aqui espero que tenham curtido, abraços e ótima semana.
