 |
| Fonte: Medusa Web Solutions |
Antes de você pensar em dizer que software legado nem sempre é um problema, vamos esclarecer o quê se está considerando como software legado neste artigo. Segundo Ward e Bennett, no livro Formal Methods for Legacy Systems (1995), software legado pode ser informalmente definido como aquele que executa tarefas úteis para a organização, mas que foi desenvolvido utilizando-se técnicas atualmente consideradas obsoletas. Logo, nem todo software antigo é legado. A palavra legado, neste caso, traz um sentido pejorativo, similar ao adjetivo obsoleto. Em outras palavras, software legado é um software antigo que, apesar de ainda ser utilizado, foi desenvolvido sem preocupação com as boas práticas de desenvolvimento vigentes e, às vezes, utilizando uma plataforma já descontinuada. E isso é necessariamente um problema? Em geral sim, por três razões principais.
Portabilidade x disponibilidade
A primeira razão é a incompatibilidade com plataformas operacionais mais recentes. E atualizar as plataformas operacionais é uma realidade em qualquer empresa que queira garantir a disponibilidade da solução e os contratos de suporte. Software legado em geral não é portável para novas plataformas e mesmo que seja, geralmente demanda um grande esforço de adaptação. Esse problema não é lá tão impeditivo, ainda mais com as novas tecnologias de virtualização, mas o risco de não funcionar sempre existe e só piora com o tempo.
Boas práticas x manutenibilidade
A segunda razão está relacionada com o desenvolvimento propriamente dito. Para começar, o legado, em geral, ou não possui documentação, ou, se ela existe, não foi feita de maneira adequada. E sabemos que uma má documentação compromete a manutenção do software. Aliás, todos os problemas envolvendo o legado que veremos aqui compromentem principalmente a manutenção do software. Quanto pior a documentação, mais difícil será a manutenção. Além disso, existe o problema da arquitetura de software. A arquitetura de software legado compromete a manutenção, pois em geral não prima pela modularização e, com isso, aumentam os riscos de uma alteração refletir onde não devia. Isso é muito comum em sistemas concebidos de forma estruturada, mas pode acontecer em plataformas orientadas a objetos também. A falta de modularização é um problema especialmente para a área de testes, que vai ficar sobrerragada com testes de regressão, absolutamente necessários quando se está lidando com um software pouco ou mal modularizado. Como não existem interfaces bem definidas, não há nada que garanta que uma alteração "aqui" não vai afetar um código "ali". Por fim, existe o problema da linguagem de programação, que em geral é ultrapassada. As consequências óbvias são dificuldade em encontrar mão-de-obra qualificada e impedimento para usar ferramentas mais atuais e que poderiam facilitar a manutenção e o desenvolvimento de novos módulos, tais como IDEs mais modernas.
Usabilidade
A terceira razão é que o software legado em geral apresenta problemas de usabilidade. Usabilidade de software é uma disciplina em constante evolução. As interfaces touch estão aí para provar que usar um software pode ser muito mais fácil do que se imaginava. Imagine quando as interfaces hands free se tornarem comuns! A usabilidade de software têm duas importantes funções. Uma é diminuir a curva de aprendizado, tornando o software mais intuitivo para quem usa e, consequentemente, diminuir custos de treinamento e tempo de retorno e aumentar a satisfação dos clientes. A outra função é aumentar a produtividade. Sofware com boa usabilidade não é só mais fácil de usar, mas também mais rápido. E em geral o legado foi desenvolvido em uma plataforma que impede ou inviabiliza a utilização de interfaces mais evoluidas. Pensou naqueles sistemas com interface de terminal 3270? É isso mesmo! Mas muitos sistemas mais recentes também foram desenvolvidos em uma plataforma ou arquitetura que tolhe a evolução da usabilidade. Vamos falar mais sobre isso no decorrer do artigo.
Quanto custa manter o legado?
Se você colocar no papel todo o esforço gasto para manter o legado, verá que vale mais a pena substituí-lo por um novo sistema. Vários estudos já demonstraram que isso é verdade, em especial quando se opta por soluções baseadas em SOA, que primam por uma arquitetura de software altamente robusta, escalável e manutenível. Mas, se isso é verdade, por que a maioria das empresas prefere manter o legado? Por quatro motivos principais.
Por que manter o legado?
O primeiro motivo é erro no cálculo do custo do legado. O cálculo do custo de manutenção do legado em geral é equivocado, pois não leva em conta os riscos envolvidos na sua permanência. Várias empresas estão esquecendo-se de considerar o risco de perda de capital humano e, principalmente, o risco da solução parar de funcionar. Outro erro comum no cálculo é esquecer de considerar o custo de oportunidade de investir em novas tecnologias que oferecem um custo de manutenção menor e têm o potencial de agregar mais valor ao sistema, em especial no aspecto usabilidade.
O segundo motivo é medo. Muitos gerentes de TI têm medo de migrar para novas tecnologias ou por que não confiam na tecnologia ou por que não confiam no seu corpo técnico de pessoal. Qual é o gerente que vai se arriscar a investir em uma nova solução sem a garantia de que ela vai funcionar como a anterior? Minha sugestão é que esses gerentes de TI precisam conhecer melhor as novas tecnologias e tomar medidas para aumentar a sua confiança nas pessoas, tais como promover treinamentos e aprimorar os processos de recrutamento e seleção. As tecnologias de sistemas estão evoluindo para melhor. Dizer o contrário não passa de conservadorismo e desconhecimento do que é novo. Não caia nessa armadilha! Se todos fossem medrosos, ainda estaríamos usando o MSDOS.
O terceiro motivo é ignorância. Como já foi dito no último parágrafo, o medo pode muito bem estar associado com a falta de conhecimento. Assim, o primeiro passo para resolver esse problema é conhecer as novas tecnologias. Estudar sobre novas linguagens, novos servidores de aplicação e novas arquiteturas é vital para tomar uma atitude de acabar com o legado. Investir em treinamento do seu corpo técnico também é importante.
E o quarto é último motivo é incompetência. Vamos ser honestos, existe uma manada de gerentes de TI sem o menor perfil para gerenciar e tomar decisões que envolvam riscos. A maioria dos gerentes de TI atuais eram outrora bons analistas e programadores, que foram promovidos pura e simplesmente por questão de antiguidade. Fazendo assim, as empresas perdem ótimos técnicos e ganham péssimos gerentes. É o que a administração chama de princípio da incompetência máxima. Esses caras não têm as competências gerenciais necessárias para avaliar o custo de manutenção do legado nem para conduzirem um processo de migração. Trata-se, sem dúvida, de um problema difícil de resolver. Como é desejável que esses profissionais tenham um perfil misto de técnico e administrador, as empresas precisam investir em programas para formação de gerentes e treinamento em técnicas de gestão de TI. Empresas com o problema do legado devem capacitar seus gerentes em reengenharia de software, que é a disciplina por detrás de tudo que estamos falando aqui. Isso vai garantir não só que os gerentes tomem uma atitude em relação ao legado como também vai contribuir para uma execução eficaz e eficiente do processo de migração.
Como resolver o problema?
Vamos considerar que a sua empresa resolveu tomar uma atitude em relação ao legado. E agora? Vamos analisar alguns pontos chaves para resolver o problema do legado.
O quê significa migrar o software legado?
Antes de iniciar qualquer atividade de reengenharia, é importante entender o quê significa migrar o software legado. Uma migração pode ser parcial ou, em casos mais extremos, total. Por quê? Porque, às vezes, uma migração parcial já é suficiente para evitar aqueles três problemas que consideramos no início do artigo, envolvendo a portabilidade, a manutenibilidade e a usabilidade. Por exemplo, considere um sistema legado desenvolvido em Cobol rodando em uma ambiente operacional de grande porte, como o z/OS. Aparentemente, não há que se falar em problemas de portabilidade, pois os ambientes de grande porte ainda têm vida longa pela frente e Cobol é a linguagem apropriada para esse cenário. Mas talvez a arquitetura de um sistema assim seja pouco modularizada e a interface de usuário esteja funcionando em modo terminal. O que pode ser feito? Uma migração parcial, ajustando a arquitetura de sofware, e uma nova interface já poderiam resolver o problema do legado sem mecher no núcleo do sistema. Nesse mesmo cenário, a aquisição de algumas ferramentas de apoio ao desenvolvimento também poderiam contribuir para a melhoria do processo de desenvolvimento. Já existem algumas soluções que permitem que se desenvolva para grande porte utilizando o Eclipse, por exemplo, com todas as facilidades que essa IDE pode oferecer. Ainda nesse cenário, a arquitetura de software poderia aos pouco ser modularizada, com um esquema que primasse pela coesão. Quem conhece Cobol sabe que isso pode ser feito com a utilização de subprogramas e parameters. As parameters podem funcionar como verdadeiros contratos entre os subprogramas, tal como ocorre com as interfaces Java. Portanto, migrar o software legado nem sempre significa jogá-lo todo fora e, seja como for, tudo pode ser feito de forma gradual como veremos a seguir.
Faça o novo software de forma realmente nova
Infelizmente, muitas empresas baseiam os novos software em software antigo. Fazendo assim, elas estão se tornando verdadeiras fábricas de software legado. Por isso, para resolver o problema do legado, o primeiro passo é parar de produzir software legado. Parece óbvio, mas muitas empresas acabam perpetuando o legado por não tomarem esse primeiro passo. Levante a arquitetura de software do seu sistema e mapeie os componentes. Garanta que o quê for desenvolvido seja realmente novo. Durante um tempo, o legado e o novo vão ter que conviver juntos, talvez até em uma plataforma híbrida. Isso pode parecer complexo em um primeiro instante, mas vai mitigar os riscos envolvendo o legado e facilitar uma eventual migração total do legado no futuro.
Mapeie os sistemas e defina um cronograma de migração
O próximo passo para acabar com o problema do legado é mapear os sistemas e definir um cronograma de migração. Sistemas com um maior índice de manutenção tendem a crescer mais rápido. Por isso, esses são os sistemas que devem ser priorizados em qualquer cronograma de migração. Comece com aqueles sistemas que demandam mais alterações. Deixe os sistemas mais críticos por último para que você possa amadurecer o seu processo de migração.
Cuidado com as interfaces de usuário
Muito cuidado quando pensar em migrar as interfaces de usuário de um sistema legado. Antes de qualquer coisa, garanta o apoio dos gestores e usuários do sistema. Se não, você corre o risco de desenvolver um sistema inteiramente novo e ter que continuar usando o velho só por que o cliente prefere as antigas telas. Marque uma reunião e apresente os problemas do legado, os riscos para a disponibilidade do sistema e mostre quais benefícios as novas interfaces trarão. Se o cliente não se convencer, tenha o cuidado de registrar tudo, pois se amanhã ou depois a disponibilidade do sistema pipocar você terá condições de se eximir da culpa.
Conclusão
Esse é um tema vasto e muito mais poderia ser dito. Existem livros inteiros sobre o assunto. Mas os pontos apresentados aqui podem contribuir para acabar com o problema do legado. E você? O que pensa sobre o legado? Acha que a reengenharia vale a pena? Como a empresa onde você trabalha está tratando desse assunto? Participe com seus comentários. Até a próxima semana.
Comentários