Desenvolvedor de Luvas e Arquiteto de Frameworks?
Não sou adepto da política que trata o desenvolvedor como um desprovido de inteligência! Muitas vezes vejo que se criam arquiteturas e soluções para proteger os desenvolvedores dos frameworks ou sistemas. Isso é diferente de prover uma arquitetura adequada que diminui a complexidade do desenvolvimento, alguns chama isso de parede, outros chamas de uma grande desperdício de dinheiro.
A Solução é evitar a arquitetura?
No way! A arquitetura é sobre riscos e diminuir a complexidade do desenvolvimento. Isso significa que temos que pegar as maiores pedras no arquitetura, mas isso não elimina o trabalho do desenvolvedor. Tanto é que o arquiteto se envolve nos pontos mais importantes de Design e isso é diferente de se envolver em todos os pontos.
Não se engane com os arquitetos de Frameworks!
Já vi direto isso no mercado, muita gente acha que o arquiteto é o cara que mexe com frameworks. Acha que é o cara que decide se vai usar o JSF ou GWT, se vai usar Hibernate ou JPA. Arquitetura de software é muito mais do que escolher frameworks.
Já vi pessoas que se acham arquitetos só por que escolheram os frameworks do projeto, mas ai quando você pergunta sobre os requisitos mais importantes do projeto? Silêncio! É você pode estar lidando com o Arquiteto de Frameworks. Que de facto não é um arquiteto, a escolha de bibliotecas a serem usadas vai muito além do modismo do mercado.
O que temos que levar em consideração para escolher um Framework?
Muitos escolhem frameworks pelo o que se fala na web em listas de discussão ou até mesmo nos grandes agregadores de informação como o InfoQ e o ServerSide. Claro que esse é um critério válido mas isso não pode ser o único critério e nem o mais importante. Existem coisas bem mais importantes como por exemplo:
A Solução é evitar a arquitetura?
No way! A arquitetura é sobre riscos e diminuir a complexidade do desenvolvimento. Isso significa que temos que pegar as maiores pedras no arquitetura, mas isso não elimina o trabalho do desenvolvedor. Tanto é que o arquiteto se envolve nos pontos mais importantes de Design e isso é diferente de se envolver em todos os pontos.
Não se engane com os arquitetos de Frameworks!
Já vi direto isso no mercado, muita gente acha que o arquiteto é o cara que mexe com frameworks. Acha que é o cara que decide se vai usar o JSF ou GWT, se vai usar Hibernate ou JPA. Arquitetura de software é muito mais do que escolher frameworks.
Já vi pessoas que se acham arquitetos só por que escolheram os frameworks do projeto, mas ai quando você pergunta sobre os requisitos mais importantes do projeto? Silêncio! É você pode estar lidando com o Arquiteto de Frameworks. Que de facto não é um arquiteto, a escolha de bibliotecas a serem usadas vai muito além do modismo do mercado.
O que temos que levar em consideração para escolher um Framework?
Muitos escolhem frameworks pelo o que se fala na web em listas de discussão ou até mesmo nos grandes agregadores de informação como o InfoQ e o ServerSide. Claro que esse é um critério válido mas isso não pode ser o único critério e nem o mais importante. Existem coisas bem mais importantes como por exemplo:
- Atender os Requisitos Funcionais
- Atender os Requisitos Não-Funcionais
- Riscos associados a esse Framework
- Facilidade de uso e número de profissionais do mercado que sabem usa-lo
- Escalabilidade da solução
Esses são os "Desenvolvedores" que não querem botar a mão na massa. Quem acham que desenvolver um Message Driven Bean é coisa de arquiteto, que acham que entender de transação, isolamento e lock é papel único de Arquiteto e DBA.
Concordo que um desenvolvedor de negocio é diferente de um desenvolvedor de sistemas! Porem essas não são coisas de outro mundo e muito menos tecnologias apenas para arquitetos. Assim acaba existindo um cultura do: "Opa! Isso não é comigo é coisa da Arquitetura". Infelizmente o Arquiteto de Frameworks acaba aumentando este mal. Logo Arquiteto de Software é != de Arquiteto de Frameworks!
Não existe mágica!
A Arquitetura é um excelente prática para o desenvolvimento de software e não posso dizer que isso não tem riscos, mas o risco esta no seu arquiteto, ou no, suposto arquiteto! A Arquitetura não pode tirar todas as decisões técnicas do desenvolvedor, essa é justamente a função do arquiteto que é saber quando e com o que se envolver.
Quando falo em se envolver não digo virar as costas para o desenvolvimento, pelo contrário, o arquiteto é um lider também. Falo em relação a construção de código na arquitetura! Quanto menos melhor! Quanto mais reaproveitamento e integração do que já existe melhor!
Concordo que um desenvolvedor de negocio é diferente de um desenvolvedor de sistemas! Porem essas não são coisas de outro mundo e muito menos tecnologias apenas para arquitetos. Assim acaba existindo um cultura do: "Opa! Isso não é comigo é coisa da Arquitetura". Infelizmente o Arquiteto de Frameworks acaba aumentando este mal. Logo Arquiteto de Software é != de Arquiteto de Frameworks!
Não existe mágica!
A Arquitetura é um excelente prática para o desenvolvimento de software e não posso dizer que isso não tem riscos, mas o risco esta no seu arquiteto, ou no, suposto arquiteto! A Arquitetura não pode tirar todas as decisões técnicas do desenvolvedor, essa é justamente a função do arquiteto que é saber quando e com o que se envolver.
Quando falo em se envolver não digo virar as costas para o desenvolvimento, pelo contrário, o arquiteto é um lider também. Falo em relação a construção de código na arquitetura! Quanto menos melhor! Quanto mais reaproveitamento e integração do que já existe melhor!
