Provavelmente um dos dilemas que as 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 aposentá-la?

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.

Satisfação do usuário

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 seja intuitiva (orientada a processos), multilíngua, que possa ser instalada nas nuvens (cloud computing) ou que 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 dizer que fica mais em conta comprar um carro novo com todos os acessórios do que 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 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. [Webinsider]

Eduardo da Cunha

Eduardo da Cunha é professor da área de TI e foi diretor de tecnologia da LG lugar de gente.