Ansioso para ver quão bem o assistente de upgrade que a Microsoft forneceu migraria aplicativos Visual Basic 6 para o novo ambiente de desenvolvimento .Net, Christopher Pesola experimentou um release beta no início de 2002.
Pesola, diretor adjunto de serviços de aplicação da Learning Care Group, empresa norte-americana especializada em educação infantil, descobriu que a ferramenta era capaz de converter de 75% a 80% do código VB6 dos aplicativos “leves” da empresa – aqueles com menos de 1,5 mil linhas de código. Mas se saiu muito pior com o aplicativo VB6 “pesado” que seus 470 berçários usam para gerir suas operações, migrando apenas 20% de código. “Não valia a pena para nós”, diz Pesola.
Um número cada vez maior de instalações de TI se confronta com a decisão de modernizar ou não seu envelhecido código VB6. Em alguns casos, isso acontece porque a Microsoft encerrou a fase de suporte regular gratuito para a ferramenta VB6 em 31 de março. Mais de 7 mil pessoas – incluindo mais de 250 Most Valuable Professionals que a Microsoft homenageou por suas contribuições a comunidades técnicas – assinaram desde março uma petição online para persuadir a Microsoft a continuar suportando, desenvolvendo e atualizando a linguagem VB core.
Este alvoroço se deve, em parte, às diferenças substanciais entre os ambientes de desenvolvimento VB velho e novo. VB.Net utiliza runtime (tempo de execução), bibliotecas de classe e modelos de objeto diferentes. E os desenvolvedores, com freqüência, enfrentam uma curva de aprendizado de moderada a íngreme para dominar o framework .Net e mudar para o modelo de programação orientado a objeto que lhes permitirá colher todos os benefícios do novo ambiente.
A Microsoft não deu sinais de ceder às demandas dos manifestantes, sustentando que eles representam uma minoria dentre os milhões de desenvolvedores VB. A maioria dos usuários prefere as novas ferramentas, principalmente para criar aplicativos baseados na Web, diz a empresa. De qualquer forma, a Microsoft prometeu aprimorar suas ferramentas de migração e a interoperabilidade entre VB6 e VB.Net, que será chamado VB 2005 no próximo release, previsto para novembro.
Neste ínterim, as empresas vão continuar a pesar suas diversas opções. Elas podem rodar seus aplicativos VB6 até que eles percam a utilidade; usar o assistente de atualização .Net e reescrever código que não converte automaticamente; migrar partes de um aplicativo para .Net e deixar o restante no VB6; reescrever um aplicativo em VB.Net ou outra linguagem, como C# ou Java; ou mudar de aplicativo.
A Microsoft diz que uma instalação de TI provavelmente vai experimentar cada uma destas abordagens em uma ou outra ocasião, com a decisão dependendo muito da qualidade do código VB6 e do valor do aplicativo para o negócio.
O Learning Care Group experimentou o code adviser (analisador de código) e assistente de upgrade da Microsoft com todos os seus seis aplicativos VB6. As ferramentas analisaram o código linha por linha, modificaram as porções que podiam ser migradas para .Net e identificaram as porções que não podiam ser migradas. A empresa teve, então, de optar entre reescrever as partes problemáticas em VB6 e tentar o assistente outra vez ou reescrevê-las em .Net.
Pesola decidiu reescrever porções de um pequeno aplicativo de registro de chamadas de serviço ao cliente e passou cerca de cinco dias desenvolvendo-o, implementando-o e testando-o. Mas esta foi a única vez que a Learning Care optou por este caminho de migração. A empresa substituiu dois aplicativos VB6 por software empacotado. Ela está em busca de uma opção melhor para um aplicativo usado por seu grupo de finanças. E percebeu que um aplicativo VB6 não era mais muito utilizado e decidiu deixá-lo rodando como está.
Para seu aplicativo de gerenciamento de centro de day care mais importante, a Learning Care elaborou um processo de licitação depois de descobrir que apenas 10% a 20% do código seriam convertidos. Pesola tentou o processo de reescrever para poder converter 50%. Mas, quando chegou a 25%, percebeu que o esforço não valeria a pena por causa das limitações de funcionalidade do aplicativo. A Learning Care pagou cerca de um milhão de dólares por um novo aplicativo baseado em .Net da NuSoft Solutions Inc., uma Microsoft Gold Certified Partner, e espera manter o aplicativo por conta própria durante um ano ou dois.
O processo de tomada de decisão será muito mais complicado para a corretora A.G. Edwards, que tem cerca de 700 aplicativos VB6 e, até agora, só migrou cerca de meia dúzia para Java ou VB.Net, de acordo com David Strickland, arquiteto de portfólio corporativo da empresa. Strickland diz que não tem sentido fazer ajustes em aplicativos VB6 simplesmente para que eles rodem em .Net. Ele quer que a empresa converta seus aplicativos cliente/servidor em aplicativos “multinível” bem projetados capazes de usufruir melhor as novas capacidades de .Net.
Tendo em vista que 65% dos 190 programadores da A.G. Edwards trabalham em VB6, transferir os desenvolvedores para o novo ambiente será tão vital quanto migrar os aplicativos. A empresa está montando um centro de competência para ajudar seus desenvolvedores a trabalhar rapidamente não só em .Net, como também em uma nova linguagem. Strickland considera a linguagem C# da Microsoft uma opção estratégica melhor do que VB.Net, já que, do ponto de vista da sintaxe, é mais semelhante a Java, linguagem que todos os outros desenvolvedores da empresa usam. “Se eu mudar para C#, o pessoal de VB pode chegar lá mais facilmente porque a plataforma é a mesma. Eles estão acostumados ao conjunto de ferramentas”, diz Strickland.
A A.G. Edwards reconhece que provavelmente terá de fazer muita codificação nova para substituir seus velhos aplicativos VB6. A empresa também está investigando a possibilidade de recorrer a um fornecedor para ajudá-la em um “salto duplo”, migrar primeiro para VB.Net e depois para C#, explica Strickland. “Outros aplicativos VB6 provavelmente serão ‘aposentados’ ou substituídos por pacotes”, prevê.
Com aplicativos cliente/servidor típicos, “onde tudo está emaranhado”, a escolha costuma deixar o aplicativo em paz ou substituí-lo, segundo Carl Zetie, analista da Forrester Research. Mas uma instalação de TI tem uma boa chance de extrair interfaces utilizáveis com um aplicativo VB6 bem projetado que tem layers de apresentação, lógica do negócio e banco de dados.
Foi nesta situação em que se encontrou a seguradora norte-americana Berkshire Life Insurance Company of America com seu sistema de reclamação de seguro por invalidez em três níveis. A subsidiária da Guardian Life Insurance Company of America conseguiu migrar seu aplicativo VB6, uma camada de cada vez, deixando partes em VB6 quando não havia uma boa motivação de negócio para atualizar para .Net.
Os desenvolvedores começaram no back end, reescrevendo a camada de acesso a dados em C# e ADO.Net, uma mudança que aprimorou a performance de acesso a dados em cerca de 20%, de acordo com Tim Murray, analista de sistemas. Os desenvolvedores também se sentiram mais produtivos no novo ambiente porque .Net está mais próxima do código plumbing.
A Berkshire Life está no processo de migrar o layer de apresentação para .Net, mas os desenvolvedores deixaram a lógica do negócio em VB6 porque não viram benefícios em migrar mais de 100 mil linhas “que, basicamente, funcionam”, diz Bill Chandler, segundo vice-presidente de sistemas corporativos. “Nada em .Net mudaria o modo como escrevemos estas regras”, observa Murray.
O recurso Component Object Model (COM) Interop de .Net permite que a equipe mantenha referências a antigos VB6 Dynamic Link Libraries. A empresa enfrentou o “inferno DLL” quando o aplicativo não conseguiu encontrar as velhas bibliotecas de que precisou, em alguns casos, com DLLs de terceiros. Para contornar o problema, eles puseram wrappers (invólucros) VB6 ao redor destas DLLs, explica Murray. “No geral, tivemos uma experiência muito positiva com .Net e sua interoperabilidade com VB6”, diz Scott Dougherty, outra analista de sistema da Berkshire Life.
Jackie Goldstein, diretor da Renaissance Computer Systems, empresa israelense que participa do programa Regional Director da Microsoft, teve “conversas ridículas” com clientes que lhe pediram para ajudá-los a traçar um plano para migrar milhões de linhas de código. Goldstein desaconselha-os a fazer isso. Wrappers que são gerados automaticamente para COM DLLs existentes funcionam bem na maioria dos casos e só vez por outra requerem “um pequeno trabalho de correção” ou um adaptador. “Não existe bala de prata para migrar, reescrever ou converter”, adverte Goldstein. “Antes de se preocupar em migrar linhas de código, você deve pensar na arquitetura”, afirma.
Uma análise de código profunda é vital para qualquer empresa que esteja migrando para .Net, acredita Billy Hollis, membro do programa Regional Director e proprietária da empresa de consultoria Next Version Systems. Segundo Hollis, a tendência dos desenvolvedores VB6 é escrever código para corrigir um problema. Mas eles precisam aprender a escrever menos código e deixar que .Net Framework faça o trabalho para eles.
“Talvez você gaste três horas para pesquisar o framework e descobrir algo que faz de 90% a 100% do que você quer”, ressalta Hollis. “Ou talvez você tenha que estender o framework. Mas, em geral, isso é mais eficaz do que escrever código a partir do zero.”
(Carol Sliwa, com tradução de COMPUTERWORLD)
