Estes textos de um ano de Piotr Solnica são sobre Ruby On Rails…
…mas as experiências neles relacionadas devem ser valiosas para quem usa ou constrói um framework PHP completo (eu posso imaginar isso se aplicando a CMSs também).
Será que essa história de Piotr faz você lembrar de algum projeto baseado em framework no qual você trabalhou em PHP?
Uma vez, eu ingressei em um projeto já existente. Foi um aplicativo muuuuito grande que estava executando um site comunitário de compras online. Modelo de vendas complicado, promoções complicadas, configurações do produto complicadas, cupons, grupos de usuários, mensagens – ele tinha tudo isso. Eu me juntei a eles para ajudar a enviar alguns novos recursos. Uma das minhas primeiras tarefas foi… adicionar um link para algo em alguma página. Demorei alguns dias para adicionar esse link estúpido. Por quê? O aplicativo era uma grande bola de lógica de domínio complexo espalhada em várias camadas com modelos de visualização muito complicados. Nem mesmo era simples encontrar o modelo certo onde o link deveria ser adicionado. Como eu precisava de alguns dados para criar esse link, não era óbvio como eu deveria obtê-lo. Havia uma falta de APIs de aplicativos internos, e confiar no ActiveRecord exclusivamente tornou aquilo extremamente difícil.
Eu consultei sobre projetos como esse mais de uma vez. Na verdade, os textos poderiam muito bem ter sido legendados como “Os Perigos do Desenvolvimento Orientado à Conveniência”:
As pessoas são atraídas pelo Rails porque ele lhe dá uma falsa sensação de simplicidade, enquanto o que realmente acontece é que a complexidade está sendo escondida por interfaces convenientes.
Leia os dois textos e veja se você pode relacionar. Eles apenas reforçam para mim que é isso que devemos esperar quando você incorpora sua lógica de domínio em sua lógica de interface de usuário.
Lembre-se: com aplicativos baseados na web do lado do servidor, a interface do usuário é a solicitação e resposta HTTP. Qualquer código que lê a partir da solicitação ou que escreve para a resposta, faz parte da interface do usuário. Colocar sua lógica de domínio na interface do usuário é conveniente para começar, mas assim que as coisas se tornam ainda um pouco complexas, essa “conveniência” se torna um fardo.
***
Paul M. Jones faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://paul-m-jones.com/archives/6577.
Powered by WPeMatico