Quantas vezes olhamos para nossos projetos, torcendo o nariz e falando aos quatro ventos "hoje eu faria tudo diferente"? Pois é. Para quem se preocupa com a arquitetura de seus projetos, além da funcionalidade em si, esse parece ser o calcanhar de Aquiles de muitas aplicações que encontramos hoje. Muitos sistemas legados com alta complexidade necessitam de uma atenção especial na refatoração. Porém, tudo na vida tem um limite, e aqui este limite chama-se bom senso. A refatoração muitas vezes é (mal) interpretada como "jogar tudo fora e começar novamente". Nós que trabalhamos com codificações intensas sabemos que isso é inviável. Então, o que fazer, como começar?
Abaixo cito algumas dicas de quais pontos você pode identificar em seu projeto em que poderá fazer uma refatoração:
1) Identifique as fraquezas de seu projeto.
Você sabe. Sempre tem aquele módulo do sistema que não gostamos nem de abrir o fonte, por "medo" de alterar alguma coisa e tudo parar de funcionar de uma hora para outra. Se isso está acontecendo em seu projeto, é um claro sinal de que este módulo foi mal projetado. As alterações não deveriam causar tanto estardalhaço no que já está funcionando, e esse "medo" não deveria existir. Procure separar as partes críticas deste módulo em camada e torne-as coesas. Isso simplifica as coisas. Faça com que cada módulo tenha sua responsabilidade específica e nada mais. Claro, se você está em um ambiente OO isso fica muito mais transparente, mas é possível sim aplicar a mesma coesão e baixo acoplamento em outros tipos de estruturas (funções, procedures, etc).
2) Pense no futuro.
Ok. Aí você vai me dizer que NUNCA esse módulo/funcionalidade vai ser usada em outra situação, que é um problema muito específico. Aí no mês seguinte alguém pede uma coisa muito parecida, com algumas alterações apenas. Já que estamos refatorando nossa aplicação, por que não torná-la um pouco mais "genérica" e menos inútil? Você sabe qual é a única constante no desenvolvimento de Software? Se respondeu ALTERAÇÃO, está no bom caminho. Muitas vezes isso exige mais escrita de código. Mas pense em você, que no futuro não vai querer ter que decifrar o que esse maldito código está fazendo.
3) Faça o uso de boas práticas de programação.
No seu módulo legado você tem variáveis com nomes totalmente insignificantes, como "x" e "y", ou "percentual". Não custa seguirmos as boas práticas de programação. Leia os padrões de projeto que gurus resolveram utilizando a mesma linguagem que você utiliza. É muito recompensador você ler um código depois e ver que ele está organizado e limpo, e que outras pessoas conseguirão compreender com facilidade.
4) O fim.
Você saberá a hora certa de virar a página. Não tente refatorar o projeto para que se torne "o sistema perfeito". Como já dito, tenha bom senso. A hora que o sistema estiver estável e que novas alterações que possam vir a surgir no futuro não sejam uma terrível dor de cabeça, você está pronto para de uma vez por todas colocar um ponto final, e a partir disso só manter.
Enfim, há com certeza mais de quatro dicas para incentivá-lo a refatorar, mas por hora isso já basta. Lembre-se, quanto menos seu projeto for frágil, mais feliz você será e menos retrabalho terá. Consequentemente, poderá alocar mais tempo em outros projetos.
Por hoje é só, um abraço.
Nenhum comentário:
Postar um comentário