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 chamam isso de parede, outros
chamam de um 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 na 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 muito 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 aí
quando você pergunta sobre os requisitos mais importantes do projeto?
Silêncio! É você poder estar lidando com o Arquiteto de Frameworks. Que
de fato 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 usá-lo
• Escalabilidade da solução

Normalmente
o Arquiteto de Frameworks pode estar seguido dos desenvolvedores de
luvas! Esses são os desenvolvedores que são um tipo de pseudo
desenvolvedores.

Esses são os “Desenvolvedores” que não querem botar a mão na massa. Quem acha que desenvolver um Message Driven Bean é coisa de arquiteto, que acha 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! Porém essas não são coisas de outro mundo e muito menos
tecnologias apenas para arquitetos. Assim acaba existindo uma 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 está 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 líder também. Falo em relação à
construção de código na arquitetura! Quanto menos, melhor! Quanto mais
reaproveitamento e integração do que já existe, melhor!