Rapid Application Development - ser ou não ser rápido ?

O RAD, como ficou conhecido, começou a surgir junto com o Visual Basic. A idéia era permitir o desenvolvimento rápido com um mínimo de código. Tornar possível que o desenvolvedor se concentrasse nas regras de negócio da aplicação que estava desenvolvendo e não em códigos acessórios era o objetivo - mais parecendo uma utopia.

O que antes era lógica e algorítimo se tornou configuração, junção de peças e organização de componentes. A lógica e algorítimo se acomodaram sobre o funcionamento das pecinhas, funcionando como uma cola a fazer toda a junção de componentes para chegar ao resultado final, o sistema.

Toda a evolução pode ser resumida em uma palavra : Abstração. Tanto da roda para o carro, como do Assembly para o Pascal, da interface de texto para a interface gráfica e do Clipper para o Visual Basic/Delphi com RAD a evolução caminhou sempre no sentido da abstração - o individuo ganha a possibilidade de se despreocupar a respeito da forma de funcionamento de elementos mais simples e passa a utilizar estes elementos mais simples para construir elementos mais complexos, tendo a certeza de que os mais simples já funcionam.

Claro que existem momentos em que o individuo precisa voltar a suas origens. Um grande exemplo disso foi a cena de "Naufrago" onde Tom Hanks precisou aprender a acender fogo com os pauzinhos. Nem ele, nem 99.9% da plateia lembravam que para acender fogo com pauzinhos era necessário um fluxo de ar. Fez falta para o Tom Hanks ? Fez alguma falta quando ele ficou perdido em uma ilha deserta depois de um desastre aéreo no meio do oceano. Mas se você não for nenhum paranóico que passou a ir ao dentista sempre antes de pegar um vôo após ver aquele filme, então a abstração de conhecimentos passados não será problema para você.

Existem momentos em que a abstração funciona perfeitamente. Responda rápido : Quantas linhas de assembly você consegue escrever ? Ainda assim consegue programar, certo ? Isso é a abstração.

Mas existem momentos em que a abstração não funciona tão bem. Alguém lembra do Kit 5 ? Foi muito famoso na época do Clipper, mas hoje praticamente não é lembrado. O que deu errado na abstração oferecida pelo Kit 5 ?

A resposta pode não ser tão óbvia, mas ela está lá : Quando a abstração limita o resultado final e a aplicação  da criatividade para as necessidades de quem está usando a ferramenta, a abstração é rejeitada e as pessoas preferem utilizar a tecnologia base devido a versatilidade que esta fornece.

Portanto, no avanço tecnológico existem tentativas de abstração que funcionam e tentativas de abstração que fracassam, o Kit 5 é um exemplo de uma tentativa de abstração que não foi para a frente, outro exemplo foram os recursos específicos criados pelo Interdev (e porque não dizer FrontPage), recursos tão específicos que ficavam extremamente presos com a ferramenta.

Por outro lado o avanço tecnológico sempre continua. Na continuidade do avanço tecnológico mesmo as abstrações que eram vistas como boas podem passar a ser vistas como algo ruim. Esse fenômeno aconteceu com o Visual Basic, mais ou menos de sua versão 4 até sua versão 6.

Inicialmente excelente para aumentar a produtividade, aos poucos as tecnologias que forneciam o RAD do Visual Basic começaram a ser discriminadas como sendo técnicas pouco profissionais, funcionando como a assinatura de um sistema amador.

Mas por que isso aconteceu ?

Porque neste período entre a versão 4 e versão 6 do visual basic coincide com o período em que se começou a utilizar bancos de dados client/server. Era uma metodologia nova para a época e os desenvolvedores ficavam confusos com relação a sua utilização.

Ok, tudo bem. Mas o que tem uma coisa a ver com outra ?

Para o R.A.D. funcionar adequadamente com o client/server eram necessárias diversas configurações específicas que muitos desenvolvedores não sabiam realizar. Com isso as aplicações feitas por meio de RAD acabavam com uma performance sofrível e inúmeros problemas.

Quando o desenvolvedor resolvia fazer a aplicação "na mão" (aqui um parentesis : "fazer na mão" se tornou um termo classico do meio da abstração tecnológica, significando burlar a abstração atual, mas podendo referir-se  a inúmeros níveis de abstração diferentes. O que hoje é abstrair amanhã será "fazer na mão") acabava como consequencia estudando em detalhes as melhores formas de fazer, ou pelo menos fazendo copy/past de outros sistemas prontos e com isso chegando a um resultado melhor do que o R.A.D.

As técnicas de RAD, porém, se tornavam pobres vítimas do desconhecimento do desenvolvedor. Elas podiam fazer muito melhor, mas eram discriminadas. A grande maioria dos desenvolvedores que dizia que os objetos RAD eram ruins diziam isso por terem ouvido falar ou por alguma experiência não muito técnica com os mesmos.

Não estou de forma alguma inocentando o RAD da época e dizendo que era uma maravilha tecnológica. Não era. Tinha os seus problemas, bugs nos componentes visuais, até muitos bugs nos componentes visuais, porém o RAD não era em definitivo a porcaria que os desenvolvedores faziam parecer, sem nem saber porque o chamavam de porcaria.

Eis então que surge o .NET. Anders Hejlsberg, que já tinha dado uma amostra de seu trabalho com o Delphi, mostrou do que sua criatividade é capaz. Ninguém lembrou de dizer para o sujeito que era impossível, então ele foi lá e fez : Mudou por completo a forma de se fazer RAD, sem porém mudar o seu resultado (os bons resultados, quero dizer)

O conceito de RAD mudou completamente. A sigla e seu objetivo final continuaram sendo os mesmos : Uma forma rápida de realizar desenvolvimento de software, desenvolvendo de forma visual. Mas o meio de chegar a esse resultado mudou. No ambiente não gerenciado, para chegar a este resultado eram utilizados componentes "fechados", que faziam tudo por si só dependendo apenas de pequenas configurações. No ambiente do .NET o RAD passou a ser feito com geração de código. Tudo, cada detalhe do que se arrasta para dentro de um formulário gera código fonte acessível para o programador.

Com o novo RAD, por que fazer tudo na mão ? Na pior das hipóteses utilizavamos o RAD e depois alterávamos o código para ficar da forma como desejávamos, ainda assim ganhando em produtividade. Quantos, porém, realmente criaram o hábito de personalizar o código gerado por um simples windows forms, por exemplo ?

Desta forma a radical mudança no significado do RAD durante surgimento do .NET gerou uma maior confiança por parte dos desenvolvedores, mas nem por isso fez com que os desenvolvedores tivessem que usar o recurso de personalizar o desenvolvimento "manualmente", especialmente porque a Microsoft teve a oportunidade de, criando uma ferramenta nova, corrigir erros de configuração e performance das antigas ferramentas - afinal, tudo começou novamente do zero.

Falamos muito de windows forms até agora, mas e o ambiente web, como se encaixa em tudo isso ?

No principio, era o substantivo. HTML, Javascript, CSS, ASP e nos tempos mais atuais até um pouco de XML. Todos esses substantivos eram necessários para o desenvolvimento de uma aplicação web. O desenvolvedor precisava dominar todos os detalhes destas tecnologias, saber como integrar essas tecnologias e entender como utiliza-las para manipular os protocolos da web e chegar ao resultado desejado.

Várias tentativas foram feitas para se chegar a um nível de abstração ideal. Primeiramente FrontPage e Interdev começaram a fazer uma abstração de forma equivalente a abstração existente no ambiente windows. Porém com toda a complexidade do ambiente web, não agradou. O desenvolvedor ainda estava tentando entender as tecnologias do desenvolvimento web e já lhe era oferecido um nível de abstração mais alto para estudar, mas preso a estas ferramentas. Pouco versátil, o desenvolvedor dispensou.

Então surgiu o DreamWeaver Ultradev. Ao invés de tentar componentes amplos, o DreamWeaver investiu na montagem de código através de wizards, deixando o código a disposição do desenvolvedor (semelhança com .NET alguns anos antes, não ?). Foi um grande sucesso entre os desenvolvedores.

A etapa seguinte foi o surgimento do ASP.NET. O ASP.NET foi uma grande evolução no desenvolvimento web, pois conseguiu dar um enorme salto no nível de abstração do desenvolvimento, aproximando o desenvolvimento web do desenvolvimento windows e sem sofrer rejeição do público por causa disso.

A abstração no ASP.NET divide-se em duas partes que utilizam metodologias distintas : Primeiramente o ASP.NET em si, que se apresenta ao programador como uma nova forma de programar baseada em tags e código e abstraindo muito, muito mesmo do trabalho anterior com técnicas semelhantes a do Frontpage e Interdev.

Mas se o Frontpage e o Interdev deram errado, por que o ASP.NET funcionou ?

Simples : Porque conseguiu fazer uma abstração mais versátil, mais flexivel e aberta a criatividade do desenvolvedor. Enquanto os dois anteriores se baseavam em uma coleção enorme de bibliotecas de código difíceis de organizar, o ASP.NET trazia uma escrita simples de tags que apenas se transformavam em código client em momento da compilação, longe dos olhos do programador. Todo o trabalho do programador poderia ser feito com as tags em alto nível mesmo desenvolvendo no notepad se desejasse.

Mas o ASP.NET trouxe também um 2o nível de abstração : Wizards no Visual Studio para a geração das tags ASP.NET. Wizards e recursos configuráveis de forma altamente flexivel e mantendo o padrão de deixar o código fonte visivel ao programador - só que desta vez um código fonte ASP.NET seguindo a abstração anterior.

A produtividade do desenvolvimento web com o uso do ASP.NET foi as alturas e se tornou um marco na evolução tecnológica para a web. Porém conforme a evolução dava saltos cada vez maiores (em 2005 o salto do framework 1.1 para o framework 2.0 foi muito considerável) se tornava cada vez mais complexo o aprendizado da tecnologia.

Para aqueles que acompanharam a evolução desde o inicio, a tecnologia é um verdadeiro livro aberto. Porém, para quem entra no estudo da tecnologia nos dias de hoje, ver o que o ASP.NET 2.0 é capaz de fazer parecer pura magia e exige um grande esforço para analisar toda a arquitetura do ambiente e compreender como aquilo que inicialmente parece mágica na verdade se encaixa perfeitamente com os conceitos técnicos da web.

Iniciar o trabalho com ASP.NET nas versões atuais, porém, tem um efeito muito diferente de quem acompanhou a sua evolução desde o principio. Iniciando nas versões atuais, o desenvolvedor fica dividido entre dois ambientes : as linguagens base da web e o ASP.NET. É claro que o ASP.NET é muito mais produtivo, mas essa divisão e a dificuldade em compreender os "efeitos de magia" do ASP.NET acabam por gerar efeitos semelhantes ao que outros processos de abstração geraram no passado : Rejeição.

Por isso hoje é muito comum vermos algumas pessoas dizendo "prefiro produzir o HTML na mão", "Não gosto da geração automática de HTML", "fica muito lixo no resultado gerado pela renderização", só que na grande maioria das vezes essas pessoas não tem um profundo conhecimento do ASP.NET para poderem se justificar, se tornando um efeito muito semelhante ao que aconteceu com o R.A.D. entre as versões 4 e 6 do VB.

Não quero dizer com isso que o ASP.NET não tem problemas, que o ASP.NET não possa melhorar em muitas coisas. É claro que pode ! A tecnologia sempre pode melhorar ! Mas comparando-se os problemas que o RAD no ASP.NET (e porque não no framework como um todo ?) tem hoje com os problemas que o RAD do VB 6 possuia, passamos por um processo de evolução inigualável.

Quer um exemplo ? Veja o webcast de criação de uma camada de acesso a dados para web, onde uso o RAD ao extremo demonstrando que ele não apenas é eficiente mas também não gera perdas para a capacidade de manutenção da aplicação.

Assim sendo, quando vejo jovens advogando que preferem fazer "tudo manualmente" ao invés de usar as tecnologias para abstração que temos hoje, isso muito me decepciona. Desde a roda até o carro o caminho do avanço tecnológico sempre foi direcionado a abstração.

O ASP.NET tem problemas com design gráfico ? Eu diria que o Visual Studio até a versão 2005 teve problemas com design gráfico. Mas por que chutar o balde e querer fazer tudo na mão apenas por causa do design gráfico ? Não seria preferível corrigir os problemas existentes para mantermos o alto nível de abstração e produtividade, ao invés de chutar o balde e regridirmos em termos de produtividade ? Que tal assistir a um vídeo sobre como o Visual Studio 2008 lida com design e ver se realmente continua sendo preferível jogar fora toda a abstração obtida e regridir tanto ?

Uma outra clara distorção (campo de distorção da realidade ?) quando desenvolvedores dizem que preferem fazer tudo "na mão" ocorre com a criação de aplicações distribuidas. Eu posso dizer que fiz e ensinei a fazer aplicações distribuidas "na mão". Utilizávamos DCOM em alguns casos e transmissão de XML em outros, montando o XML com o DOM (Document Object Model de XML da Microsoft) e transmitindo com XMLHTTP. E olha que ainda dá para dizer que isso era muito luxo, pois pouco tempo antes tinha que ser concatenação de strings e abertura "manual" de conexões HTTP.

Tá. E dai ? Dai que surgiu o W3C e criou : SOAP, WSDL, WS-SECURITY, WS-TRANSACTIONS, WS-ADDRESSING, isso só para citar alguns dos WS* . Imagine-se tendo que seguir todos esses padrões da forma como faziamos, montando o XML "manualmente". Viável ?

Absurdo. Confesso que eu próprio, no inicio de toda essa padronização, fiquei me perguntando o quanto seria realmente vantajoso seguir os padrões se o volume de trabalho que teríamos para isso seria simplesmente triplicado.

A padronização que o W3C criou nos ensinou uma grande lição : A padronização não tem como objetivo apenas a interoperabilidade, mas também a abstração. A partir do momento em que algo é padrão, então não precisa mais ser feito por uma pessoa, pode ser feito por uma máquina.

Foi exatamente isso que aconteceu com os padrões W3C : A partir da criação dos padrões, seu uso passou a ser automatizado. Passamos do Soap Toolkit para os webServices do .NET e agora o WCF, o conceito de criação de proxys para acesso a serviços se intensificou e tais elementos passaram a ser gerados dinamicamente. Que atire o primeiro webService com suporte a ws-security, ws-transactions e com WSDL aquele que disser que prefere fazer tudo "manualmente".

O ASP.NET pode melhorar mais ? Claro que pode, assim como toda tecnologia. Mas quanto mais os desenvolvedores investirem em sugestões e formas de melhorar a tecnologia, ao invés de chutar o balde diretamente, mais e mais a tecnologia evoluirá. Chutar o balde, querer ter o controle de tudo e fazer tudo manualmente é um retrocesso, ir contra a todo o avanço tecnológico que temos desde a roda. Aqueles que assim fazem podem até estar temporariamente corretos (o que particularmente não acredito), mas cedo ou tarde a abstração, presente na evolução desde a roda, irá atropela-los.

Neste momento temos um novo dilema no mercado de desenvolvimento web : Devemos seguir adiante com o modelo de desenvolvimento que temos ou devemos mudar o caminho para a metodologia alternativa que está sendo proposta, o ASP.NET MVC ? Para entrar mais tecnicamente neste assunto escrevi os artigo Analisando o ASP.NET MVC Framework, Criando uma Cesta de Compras com o ASP.NET MVC Framework e Analisando uma Aplicação ASP.NET MVC. Só espero que não tenha acendido o pavio de um barril de pólvora.