Reescrever ou manter as aplicações antigas?

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

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 é professor da área de TI e foi diretor de tecnologia da LG lugar de gente.

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

Mais lidas

Uma resposta

  1. O processo de modernizar uma aplicação deve passar, na maioria das vezes, por uma ou mais fases de transição indo do modelo atual até chegar à arquitetura final.

    Quebrando o processo em pequenas fases oferece enormes vantagens quando comparado a um modelo de big-bang, onde se desliga o sistema antigo e liga o sistema novo depois de vários meses ou anos de desenvolvimento.

    O processo interativo permite por exemplo mitigar os riscos de um processo de modernização, que já são grandes por natureza. Isso é alcançado de várias formas: ajustes sejam feitos a cada nova etapa, usando as lições aprendidas. O treinamento e adaptação dos usuários pode ser feita de forma progressiva. O investimento na nova arquitetura pode começar a ser recuperado e avaliado em menores ciclos.

    Há diversos desafios em ambos os modelos, por exemplo, como desenvolver novas funcionalidades sem quebrar o relacionamento com a base de dados. Quando e como inserir novas funcionalidades no novo sistema, como manter compatibilidade com sistemas externos, etc.

    Os drivers para modernização de uma aplicação, como bem colocado pelo Eduardo, são diversos como satisfação dos clientes, custos operacionais, agilidade para desenvolver novas funcionalidades e adaptar à novas legislação. O que não pode ser esquecido é que o processo de modernização deve estar alinhado com as necessidades do negócio. Modernizar apenas para modernizar dificilmente justifica o investimento.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *