Sala de imprensa

Aplicações antigas: reescrever ou manter?

Releases 06/12/2010

*Por Eduardo da Cunha

Provavelmente um dos dilemas que essas organizações – seja da iniciativa privada ou de um órgão do governo – se deparam hoje em dia ou vão enfrentá-lo nos próximos anos relaciona-se com a seguinte questão: devo continuar a manter as nossas aplicações antigas ou chegou a hora de reescrevê-las? Explico-me melhor. Uma aplicação ou um software de computador geralmente é criado para atender as necessidades das pessoas (ou usuários). Acontece que, com o passar do tempo, esses usuários exigem mudanças, o que é perfeitamente normal levando-se em conta que ocorre um aprimoramento dos seus processos de trabalho. Assim, pode-se afirmar que as aplicações nascem e em seguida passam a sofrer acréscimos com as melhorias sugeridas, algumas delas, inclusive, de ordem legal.

Na medida em que as melhorias são incorporadas na aplicação, o seu código (linhas escritas numa linguagem de programação) cresce e se modifica de forma ininterrupta. Por esse motivo diz-se que uma aplicação tem vida: ela nasce, cresce e um dia morre. A sua morte significa que ela é substituída por outra. Supõe-se que a substituta vá oferecer mais vantagens aos seus usuários, tais como novas funcionalidades, facilidades de uso, maior segurança, confiabilidade e um novo ciclo de vida. Mas, quando é que tiramos uma aplicação do ar? Quando sabemos que chegou a hora de aposentar a mesma?

Aplicações que foram escritas há mais de dez anos e continuam em produção, certamente são mantidas por profissionais da área tais como os analistas, projetistas e programadores que se encarregam de incorporar as melhorias que os seus usuários solicitam. Portanto existe em cada organização um time de profissionais envolvidos com o processo de manutenção.

Bom, depois de um dado tempo a aplicação começa a sofrer um processo irreversível de deterioração do seu código. A partir desse momento, a sua vida útil está quase no fim, então ela praticamente impede que sejam incorporadas novas mudanças na sua estrutura. Em alguns casos pode-se tentar a refatoração, ou seja, executar melhorias progressivas para manter a qualidade do código. No entanto, eu vejo que esse processo nem sempre consegue acomodar as novas exigências de mercado. Aí é que entra a dúvida: vamos reescrever essa aplicação ou persistir na sua manutenção?

O tempo de atendimento é um bom critério, mas não é o único empregado para definir se a aplicação deve ser reescrita ou não. A meu ver existem outros que devem ser avaliados. No entanto, eu diria que todos eles estão intimamente relacionados com a satisfação (produtividade) dos usuários.

Então, para aumentar a eficiência do seu trabalho, os usuários requerem que a sua aplicação sofra alterações de tal sorte que ele consiga usá-la na web, empregue dispositivos móveis (celular, Ipad), lance mão de redes sociais (facebook, twitter), passe a trabalhar com maior segurança (lei Sarbanes Oxley), use uma interface rica (Silverlight), que essa seja intuitiva (orientada a processos), seja multi língua, que a aplicação possa ser instalada nas Nuvens (Cloud Computing) ou que ela seja ofertada como serviço (Software as a Service). Enfim, se nossos usuários nos solicitam o atendimento a algumas dessas necessidades, chega-se rapidamente à conclusão que fica mais em conta desenvolver novamente a aplicação do que procurar inserir tais melhorias no seu código.

Provavelmente a seguinte analogia vai permitir expor com mais propriedade esse cenário. Imagine que o proprietário de um carro da década de oitenta ou noventa chega numa oficina e diz para o mecânico: “Olhe, quero que você faça poucas mudanças no meu veículo. Instale freios ABS, um GPS, meia dúzia de Air Bags, um câmbio Tip Trônic e uma direção hidráulica”. Provavelmente o mecânico vai lhe dizer que fica mais em conta comprar um carro com esses acessórios a promover a manutenção pedida.

Eu sei bem que nós, profissionais de TI, preferimos desenvolver aplicações a manter software legado. Ao nos depararmos com novidades, os desafios atiçam a nossa curiosidade e satisfazem o nosso potencial intelectual. Entretanto deve-se deixar claro que partir para o projeto de reescrita, empregando novas tecnologias, não é uma decisão simples. Ela passa, antes de mais nada, por uma exigência de mercado. Ou seja, não devemos inovar por inovar, mas sim devemos inovar para trazer resultados, para que a organização consiga fazer mais e melhor, para que ocorra um aumento na eficiência dos processos que geram produtos e serviços que ela se propõe a realizar.

Eduardo da Cunha é diretor de tecnologia da LG Sistemas (lg.com.br), empresa brasileira desenvolvedora de software para gestão de recursos humanos.

Agende uma reunião

Entre em contato conosco e aproveite para bater um papo com um de nossos especialistas.

Preencha todos os campos marcados!

https://www.lg.com.br/