Conversão de aplicações

Pediram-me, há umas semanas, para dar uma opinião em relação a um projecto de conversão de uma aplicação já existente.
A ideia é pegar numa aplicação, desenvolvida em Visual Fox Pro, já com um curriculo interessante no que diz respeito a funcionalidades e número de instalações existentes e criar algum mecanismo que lhe permita passar a utilizar o Sql Server como repositorio de dados.
Posto de uma maneira muito simplista diriamos que queremos criar uma aplicação ou fazer as alterações necessárias na aplicação existente de forma a manter todas as funcionalidades de forma a que através de uma opção global possamos indicar gravar os nossos dados. Como disse antes, simples.

As motivações para esta decisão foram as seguintes:

  • técnica – já que o Visual Fox Pro tem uma limitação em relação ao tamanho das tabelas que “só” podem ter no máximo 2GB;
  • comercial – já que o nome SQL Server é muito mais interessante que Visual Fox Pro na mente das pessoas que têm que decidir a compra de este ou aquele produto.

Considerando aquilo que se quer propor ao utilizador final, que ignora naturalmente as diferenças entre plataformas tecnológicas, este é um projecto paradoxal já que queremos vender como um produto novo, um produto que tem que ser exactamente igual ao que já existia no sentido que tem exactamente as mesmas funcionalidades.

Por outro lado a aplicação em questão que por inerência à tecnologia já é bastante performante foi ainda sendo refinada de forma a melhorar essa performance inicial, isto leva a que seja admissivel considerar que uma mudança tão substancial de plataforma tecnológica, leve a um decréscimo, mais ou menos pronunciado dessa performance. Ou seja poderá dar-se o caso do utilizador passar da versão actual para a nova versão que faz exactamente o mesmo mas mais devagar.

Outro ponto importante a ter em conta diz respeito à base inicial de trabalho no que diz respeito ao código e ao próprio ambiente e processo de desenvolvimento. 
O Visual Fox Pro é um produto bastante diferente das linguagens/plataformas da moda (.net e java), já que faz parte do mesmo ramo que o dBase e seus descendentes sendo por isso uma linguagem muito data-centric onde não faz sentido a visão que tradicionalmente nos é vendida das diferentes camadas (dados/lógica/apresentação). (Nota pessoal: não deixa de ser curioso que se trata de uma visão bem mais próxima do Progress do que de .Net)
Este paradigma data-centric permitiu opções de desenvolvimento que não são transparentes num ambiente de desenvolvimento em que temos muito claro onde estão os dados (no servidor de base de dados) e onde está o user interface (no pc do cliente).
Um exemplo muito concreto tem a ver com o preenchimento de grids. Enquanto que no Visual Fox Pro todo o processo de ir buscar os dados de uma tabela com um milhão de registo, fazer scroll up ou down, ou ir para o primeiro ou ultimo registo é bastante transparente e performante, no mundo .Net e afins este processo é mais tortuoso já que temos que aceder à base de dados, carregar tudo o que queremos e despejar no grid e assim arriscamo-nos a carregar um milhão de registos quando na verdade só queriamos meia dúzia com todo o custo de performace associado ou então a ter que implementar estratégias de paging que sendo possiveis e exequiveis representam mais linhas de código e fatalmente maior probabilidade de erros.
Claro que podemos simplesmente questionar qual o interesse efectivo de um grid com um milhão de registos mas isso implica conseguir mudar a forma como os programadores inicialmente desenvolveram a aplicação e os utilizadores que estão habituados a um determinado interface.

Finalmente sendo uma aplicação já com alguns anos e sem nenhuns testes formais desenvolvidos, e aqui estou a pensar em testes unitários, a probabilidade de cairmos em situações em que por mexer num pedaço de código estamos a afectar outro pedaço de código de que não temos noção é muito grande.

Claro que todas estas notas são simples alertas para questões que outras pessoas já sentiram e não são por si só justificativas da opção de seguir com o projecto ou de abandoná-lo.
Para chegarmos a essa conclusão temos que antes conseguir responder a outras questões:

  • o problema técnico que leva a esta decisão não consegue ser resolvido de outra forma?
  • qual o cenário previsivel de vendas desta nova versão? ou seja em quantas vendas prevemos diluir este custo em que estamos a incorrer?
  • é aceitável algum nivel de degradação de performance? se sim que quantificação objectiva podemos definir?
  • qual o âmbito real do projecto? todos os dados têm que ser guardados ou em SQL Server ou em Visual Fox Pro ou podemos ter as duas tecnologias ao mesmo tempo, por outras palavras podemos ter produtos intermédios totalmente funcionais?
  • qual a duração previsivel de vida deste produto? até onde temos que considerar questões de manutenção futura e por isso até onde devemos considerar importante o desenvolvimento de mecanismos que nos permitam melhorar no futuro o tipo e rapidez de resposta nestas manutenções?

Só depois destas resposta terem sido dadas e na certeza de que certamente que nenhuma delas é uma resposta absoluta e definitiva (grow software vs build software) é que podemos chegar a uma conclusão mais confortável já que assente em alguns pressupostos.

 

por Vitor Silva



Leave a Reply