Refatorando códigos existentes
Dentre os termos frequentemente
utilizados em desenvolvimento de software, “refatoração” é usado na maioria das
vezes de forma flexível, sendo utilizado para se referir a qualquer tipo de
limpeza no código. Recorrendo a um especialista, de acordo com a definição
presente no livro “Refactoring” do Martin Fowler, percebemos que a definição de
refatoração vai além, segue definição: “Refatoração
(substantivo): uma modificação feita na estrutura interna do software para
deixa-lo mais fácil de compreender e menos custoso para alterar, sem que seu
comportamento observável seja alterado.” (Fowler, 2020)
A definição
acima aponta para uma abordagem muito mais abrangente que uma limpeza, podendo
ser vista como uma “reestruturação” e estando totalmente ligada à aplicação de
pequenos passos que não modificam o comportamento observável da aplicação. E é a
soma desses pequenos passos que levam a uma mudança grande. É importante notar
que a cada pequena mudança realizada, nenhuma falha deve ser percebida na
utilização, ou em outras palavras, ele deve fazer exatamente o que fazia antes de
iniciar a refatoração.
Então a
ideia é que se seguirmos com a refatoração em pequenos passos, cuidadosamente,
não causaremos nenhuma falha... Mas e se eu cometer um erro? (ou melhor, quando
cometer um erro). Erros sempre acontecem, e não são um problema se
identificarmos eles rapidamente e os corrigirmos. Daí a importância dos
pequenos passos. Se a modificação realizada foi pequena, será mais fácil
encontrar onde o problema aconteceu, pois teremos um trecho pequeno de código
para verificar. Se não for possível encontrar o erro, podemos voltar a uma
versão do código que sabemos que funcionava.
Para facilitar e encontrar os
erros rapidamente, outro ponto importante é um conjunto de testes abrangente no
código e que possa ser executado rapidamente. Assim, quando um teste falhar,
poderemos olhar rapidamente para as modificações que fizemos e comparar o
código atual com o último código para o qual o teste passou. Portanto, sempre
que fizer uma refatoração, caso não existam testes para as funcionalidades que
está modificando, é fundamental criar os testes antes. Isso dará mais segurança
ao processo e também a nós programadores.
Pode-se também comparar a
refatoração com uma otimização de desempenho, pois nos dois casos realiza-se
modificações no código que não modificam a funcionalidade do sistema. Porém a
diferença está no propósito. A refatoração é sempre feita com a finalidade de
deixar o código mais fácil de entender e menos custoso para alterar, sem se
preocupar se o código ficará mais lento ou mais rápido. Na otimização a única
preocupação é deixar o código mais performático, mesmo que com isso fique mais
complexo de entender e difícil de alterar.
Neste ponto você leitor já deve
ter uma ideia do que é refatoração, mas deve estar se perguntando quais os
principais motivos para realizar uma refatoração. Pois digo que bons motivos
são: Melhorar o design do código existente, pois sem ela, ao longo da vida útil
do software e as consequentes modificações realizadas por diferentes pessoas, a
tendência natural é que o código entre em decadência. Se torna cada vez mais
difícil ver a estrutura do software e mais difícil preservá-lo. Sempre que
fizer uma refatoração, deixe o código mais fácil de entender do que antes de
iniciar, se preocupe com as outras pessoas que irão ler o código. É
relativamente fácil escrever um código que o computador seja capaz de entender,
mas o desafio e o valor maior estão em escrever um código que outras pessoas
vão poder entender rapidamente e sem grande esforço. E isso não é necessariamente
algo altruísta. A pessoa que terá de modificar o código pode ser seu eu do
futuro, daí a um ou dois anos, quando não se lembrará mais dos códigos que
criou.
Outro benefício que pode vir da
refatoração é ajudar a localizar, entender e resolver bugs. O trabalho de
entender um código para refatorá-lo certemente aumentará sua compreensão da
estrutura do programa até o ponto que será inevitável localizar os bugs. O
último motivo que darei para refatorar um código é também o mais contraintuitivo.
Na maioria das vezes, as pessoas conseguem ver o valor da refatoração no que se
refere a promover a melhoraria da qualidade possibilitando um design interno
melhor, mais legibilidade e redução de bugs. Mas e o tempo gasto com a
refatoração não deixa o desenvolvimento mais lento?
De acordo com Fowler, comparando
uma equipe que investe na qualidade interna do software: um bom design interno
que permite saber facilmente como e onde devem fazer as alterações para acrescentar
uma nova funcionalidade e uma boa modularidade que permita que só seja
necessário entender uma pequena porção do software para realizar uma alteração,
são equipes que conseguem ser mais rápidas com o passar do tempo para
acrescentar novas funcionalidades pois tiram proveito do código existente. Ao
passo que as equipes que vêm trabalhando em um sistema há um certo tempo sem
promover melhorias, dizem que no começo eram capazes de realizar progressos
rapidamente, mas agora demoram muito mais para acrescentar novas
funcionalidades e entender como elas se encaixarão na base de código existente.
Em resumo, sabemos agora que
sempre é possível melhorar o design de um código existente, mesmo que as
necessidades do software mudem. E como é muito difícil fazer um bom design
antes que o software seja desenvolvido, a refatoração se torna essencial para
caminhar em direção ao caminho virtuoso das funcionalidades rápidas. Espero que
este texto tenha agregado algum valor a você na sua jornada como programador.
Agredeço a atenção e até a próxima! Deixe seu comentário!
Comentários
Postar um comentário