Um novo paradigma em desenvolvimento Web

January 18th, 2008 § 8 comments

Ruminando nos últimos dias sobre o futuro do desenvolvimento em especial, pensando sobre o que eu andei escrevendo sobre testes e linguagens específicas de domínio, e principalmente sobre as coisas que tem chamado a minha atenção nos últimos tempos no campo, eu fiquei surpreso ao perceber que por mais que estejamos falando em novos paradigmas, nenhuma aplicação ou framework está explorando os conceitos mais novos de maneira significativa.

O histórico do área é abismal, é claro. Já estamos beirando os quarenta anos desde que alguma mudança significativa de paradigma aconteceu, e quase vinte anos desde que práticas mais estruturas se tornaram a base do que fazemos hoje. Apesar disso, a indústria permanece estagnada no campo minado que orientação a objetos, bancos relacionais, e design bottom-up representam.

Pensando em desenvolvimento Web, por exemplo, por mais inovadores que Rails e Django sejam, os dois possuem duas características que os tornam completamente inúteis a longo prazo.

A primeira característica é a fragmentação conceitual. Na tentativa de tornar o desenvolvimento “indolor”, esses dois frameworks e seus descendentes diluem o domínio da aplicação em uma série de pequenos pedaços que, embora representem uma forma mais gerenciável de desenvolvimento, também tende a criar uma desconexão entre o código e aquilo que ele deve representar.

A segunda característica é a fixação em soluções constritas. O uso de REST pelo Rails é um bom exemplo disso. Embora REST seja um conceito interessante e mesmo necessário para uma classe de aplicações, a implementação do Rails é limitada, dependente de truques, e sofre da mesma fragmentação citada acima.

De fato, muito do que a maioria dos frameworks modernos estão fazendo é pretender que a complexidade não existe ou que ela pode ser gerenciada com o uso de métodos pequenos e testes.

Desenvolvimento guiado por testes, ao contrário do que se prega atualmente, não é uma bala de prata. Antes, é mais uma prática que está sendo transformada através de uma falta de compreensão em uma panacéia–como algo, inclusive, que pode guiar o design de sua aplicação até o ponto em que não é necessário fazer uma análise apropriada do domínio do problema. A quantidade enorme de exemplos mostrando como testar algo que, por definição, já está testado é insana. Eu sou tão culpado quando o próximo programador ao fazer isso em minha própria documentação.

E por mais que eu defenda Seaside, por sua aplicação inovadora de conceitos antigos e por sua recusa em se ater às soluções supostamente provadas, o fato é que, a exemplo dos outros frameworks, Seaside também não é uma solução que parte de premissas radicalmente diferentes das que a indústria tem oferecido nos últimos anos.

Algo que está me dando esperança de que as coisas podem mudar logo é o interesse em programação orientada a linguagens. Se isso se transformar em uma característica dominante das linguagens que estão crescendo hoje, podemos experimentar uma renovação conceitual nos próximos anos.

Talvez o que precisamos é de uma forma de gerar especificações executáveis que seja realmente uma forma de criar aplicações e não uma maneira inferior de modelar o comportamento esperado de uma aplicação. Isso é algo para se pensar.

Talvez aqui esteja uma meta para esse ano: tentar descobrir uma forma de combinar as peças que estão soltas, peças geradas nos últimos vinte anos que parecem estar a uma pequena distância de uma revolução. Alguém de habilita?

§ 8 Responses to Um novo paradigma em desenvolvimento Web"

  • Interessante, Ronaldo.

    Só não entendi muito bem o intuito da afirmação abaixo:

    “… embora representem uma forma mais gerenciável de desenvolvimento, também tende a criar uma desconexão entre o código e aquilo que ele deve representar.”

    Acredito que essa “fragmentação” no Rails, por exemplo, cria mais soluções do que problemas. Infelizmente ainda estamos bem presos a controllers e views (e, em muitas plataformas, ainda é pior do que isso), o que tira o foco do domínio do problema.

    Mas acho que não compreendi bem o intuito, então creio que seria interessante se você desenvolvesse mais esse argumento.

  • Ronaldo says:

    Sobre a passagem em questão, eu estava pensando em gerenciamento de complexidade e desenvolvimento bottom-up, como mostrados pelo texto ao redor. O problema da maioria dos frameworks atuais é que eles colocam um ênfase grande em interfaces–especialmente evidenciado pelo modo como TDD é usado na maioria deles–e pouco em realmente organizar um sistema a partir do domínio do problema.

    Eu entendo, é claro, que nesse sentido ainda estamos perseguindo uma solução um pouco melhor do que usamos hoje mas o tipo de metodologia empregada por Rails, Django e outros vai contra uma combinação de bottom-up e top-down que eu particulamente acho mais interessante.

    No caso do Rails, por exemplo, a ênfase na transformação de modelos em classes que atendem a um protocolo REST é um erro. É claro que em qualquer sistema, o nível de troca de informação entre objetos tende a crescer exponencialmente e o que o Rails está fazendo é fragmentar isso para tornar o processo mais gerenciável. Mas eu não sei até que ponto isso deveria ser o alvo. A solução me parece curto termo demais para valer a pena.

    O Seaside segue uma linha mais afinada com o próprio ambiente Smalltalk, focando bastante no problema mas ainda não é o ideal. Se você comparar exemplos de Seaside com exemplos em Rails, fica gritante o fato de que os primeiros estão mostrando o desenvolvimento de uma posição sistematicamente mais alta enquanto no caso dos outros, a ênfase é sempre em como o Rails reduz linhas de código, como tudo é muito simples e por aí vai. São muito raras as análises do Rails do ponto de vista de desenho de sistema. O pessoal do Rails Way estava fazendo isso mas sumiram.

    É claro que o Rails não é o culpado. Django e todos outros clones usam mais ou menos a mesma linha. É um sinal dos tempos, na verdade, e necessário. Mas eu acho que precisamos pensar um pouco mais sobre o assunto.

    Espero ter explicado um pouco mais da minha motivação.

  • agaelebe says:

    Bem, parece que é hora de você criar seu framework.

  • Samir says:

    Talvez não seja o melhor argumento mas acho que frameworks como o Rails e Django, vieram com a intenção de ajudar o programador a focar exclusivamente no problema e não na implementação, acho que isso já é um grande passo no desenvolvimento para Web, comparado com a enxurrada de XML que vemos por ai em Java e .NET.

  • Entendi melhor sim, Ronaldo.

    O “problema” é que sabemos que tem que melhorar, conseguimos dissertar sobre isso mas, quando chega a hora da implementação, ainda fica tudo um pouco nebuloso demais.

    Acredito que isso é normal pois, como ciência, a informática ainda é *muito* nova em comparação à praticamente todas as outras.

    Você tem alguma idéia de como seria uma implementação menos focada nas interfaces e mais centrada no domínio? Como você mesmo citou, talvez as especificações executáveis sejam um caminho interessante, tendo ainda muito à evoluir.

  • Ronaldo says:

    Hugo, quem me dera. :)

    Samir, sim, por isso que eu disse que Rails e Django são necessários hoje. A questão para mim é que ambos fragmentam tanto o problema por causa de idiossincrasias em cada um dos dois que acabam resolvendo um lado e atrapalhando outro.

    Lucas, realmente é um assunto meio nebuloso.

    No momento eu estou pensando em como o uso de DSL focadas em uma representação Web de um problema poderia ajudar na questão. Ainda não consegui chegar a nenhuma conclusão específica e daí o texto para tentar fomentar um debate em cima do tema. :-)

    Eu comecei a pensar em especificações executáveis depois que passei a usar o Story Runner do RSpec. O interessante do uso do Story Runner é que você tem uma mímica do que precisa resolver em seu problema em um nível mais alto. Se isso fosse traduzido em algo capturável–talvez por meio de eventos ou coisa assim–talvez fosse possível pensar na especificação como o problema.

    Bem, eu posso e deve estar viajando. Mas é um assunto ao qual pretendo me dedicar um pouco esse ano e tentar experimentar com alguma coisa.

  • Interessante.

    Talvez o caminho seja mesmo deixar de tentar adaptar o que é feito no desktop para a internet e criar algo baseado na arquitetura da mesma.

    Inicialmente poderiam ser DSLs e, depois, uma linguagem completa focada nisso (ou seja, uma grande DSL para Web 😉 ). Não estou por dentro desses assuntos, você sabe se já existem linguagens 100% focadas na web?

  • Ronaldo says:

    Sim, acho que o caminho é esse mesmo. Eu não conheço nenhuma linguagem específica para desenvolvimento Web, mas já acho que está na hora de alguma aparecer. O problema é que muita gente que tem capacidade hoje está mais intenta em copiar que criar algo novo. Mas as coisas estão andando. Quem sabe esse ano ainda não reserva alguma surpresa.

Leave a Reply

Your email address will not be published. Required fields are marked *

What's this?

You are currently reading Um novo paradigma em desenvolvimento Web at Superfície Reflexiva.

meta