dnfeitosa.com

Quem nunca sentiu a tentação de reescrever algum script, classe, função ou sistema do zero? Eu já senti, já reescrevi e sei que não estou sozinho nessa.

Em um post relativamente antigo, Uncle Bob faz algumas considerações interessantes a respeito da reescrita de um sistema do zero, partindo do princípio que a motivação para isso vem do quão bagunçado um sistema pode ter se tornado ao longo do tempo.

Nele, ele fala que recomeçar um sistema do zero é uma das piores coisas que podem ser feitas; que todos os projetos começam como um “campo verde” onde as coisas são belas, mas que numa hora ou outra este campo estará cag… bagunçado. O software terá uma quantidade enorme de bugs; programar novas funcionalidades se tornará uma tarefa cada vez mais complicada e uma reescrita parecerá a solução ideal.

Faz todo sentido, certo?

Mas e quando você está trabalhando com um sistema todo ou parcialmente baseado em tecnologias antigas (algumas descontinuadas talvez), em que o esforço da reescrita compensa no final das contas?

Ok! Não é exatamente na questão do “compensa” ou “não compensa” que eu quero chegar, mas sim, em que focar no novo projeto. O quê fazer para o novo sistema não se tornar outro pesadelo demandando uma nova reescrita?

Talvez haja mais perguntas a serem feitas antes de iniciar o trabalho, mas acho que essas são bem importantes:

- Quais idéias podem-se aproveitar do sistema antigo?

- O quê deu certo ou errado nesse sistema?

- O quê deve ser feito para não errar novamente?

- O quê pode ser melhorado?

- Qual o grande diferencial dessa nova versão?

Seguir a mesma estratégia adotada anteriormente pode não ser o caminho mais correto a ser seguido e tentar identificar os pontos falhos pode ser a diferença entre um sistema de sucesso ou um novo fracasso.

Se você sabe, por exemplo, que o grande problema do seu sistema antigo é desempenho, tente fazer as coisas de forma diferente de modo que sua aplicação responda mais rapidamente (não estou falando de otimização prematura, mas de tentar identificar os pontos que são lentos por algum erro de programação ou falha de arquitetura).

Se o seu problema é a grande quantidade de bugs e dificuldade de corrigi-los, policie-se para não deixar seu código desestruturado, bagunçado e sem testes; escreva testes o tempo todo e sinta-se seguro.

Não tenha medo de se desapegar do código antigo; esqueça o copiar e colar!

Evite falhar no mesmo ponto novamente!

Poxa! Quanto tempo pra iniciar esse blog!

Quando registrei esse domínio em fevereiro de 2006 sabia que ia demorar um pouco até fazer alguma coisa de útil com ele, mas não tinha ideia que demoraria tanto!

Muita coisa mudou durante esse tempo todo não só comigo, mas também com o mercado de TI em geral e de certa forma perdi a chance de mostrar minha postura em relação à essas mudanças.

Acho que estava mais do que na hora de pegar esse espaço que por tanto tempo foi um “repositório” abandonado de códigos antigos e obsoletos, e transformar em alguma coisa útil… ou, menos inútil.

Mas por quê tanto tempo assim pra iniciar um blog? Falta de tempo? Falta de motivação? Outras prioridades? Talvez um pouco de cada coisa ou mesmo só relaxo da minha parte.

Acho que essa não é uma propaganda muito positiva pra fazer de mim mesmo, ainda mais no começo disso aqui. Já imaginou se eu desisto do blog de vez e fico apenas com esse post estampado na tela principal, mostrando essa imagem? Vou dar um jeito de jogar esse post algumas páginas pra trás!

Quem me conhece sabe que gosto de tecnologia, principalmente coisas relacionadas à desenvolvimento de sistemas, e pretendo usar esse espaço pra falar um pouco do meu dia a dia no trabalho: as descobertas, frustrações, dicas, problemas e soluções que eu enfrento junto de meus colegas.

Tenho certeza que vou falar muita besteira também e espero que quem leia o que escrevo questione, opine e xingue quando for necessário. As críticas serão bem-vindas e benéficas para ambas as partes.

Não sei se está muito tarde pra correr atrás do prejuízo, mas antes tarde do que nunca, certo?