Arquitetura Prática

Existe um tipo de programador que denominamos na Microsoft como “Programador Prático”. Como o nome diz, ele não está interessado em grandes complexidades ou na tecnologia pela tecnologia. Ele valoriza a simplicidade e a praticidade. Ele ama poder desenvolver rapidamente algo de útil para a sua empresa.

Creio que de certa forma nós arquitetos deveríamos tê-los mais em mente. Nossos conjuntos de classes, bibliotecas e frameworks deveriam ser simples o suficiente para suportá-los. Talvez adicionando linguagens visuais (DSL’s), às vezes promovendo componentes simples para drag-and-drop.

Me pergunto também se não deveriam existir também mais “Arquitetos Práticos”. Utilizando mais a infra-estrutura e produtos de prateleira (ou COTS – Commercial of-the-shelf) e visando resultados rápidos com bom retorno de investimentos.

Entendo a tentação de projetarmos nós mesmo a nossa infra-estrutura – estudamos para isto temos muito prazer e realização nisto. Mas compreendo também que o mercado não comporta o investimento de um framework por projeto ou por empresa. Como na arquitetura civil, existem os casos das construções padronizadas e aquelas em que a arte da arquitetura pode ser plenamente exercitada.

Não sei quanto à experiência de vocês, mas tenho encontrado mais arquitetos com ânsias de artista do que profissionais objetivos e alinhados com a praticidade.

Eis um desafio para a nossa classe: ganhar a maturidade para saber quando ser um ou outro. Ou melhor: como ser os dois!

Comments

• Anonymous
  August 25, 2008
  Otávio, Eu costumo dizer a seguinte frase para minha equipe: "Se é complicado, não presta!" Claro que isso levado ao pé da letra, soa estranho e pode não trazer benefícios. Mas quando digo isso a eles, estou tentando focá-los no negócio e não na tecnologia em si. Concordo que seja bom desenvolver componentes, frameworks e outras coisas, mas o mais importante é o foco na entrega e na manutenabilidade. Se o que for gerado é difícil de manter, será um peso no futuro para a equipe; mas se o que se gera pode rapidamente ser absorvido por um estagiário ou pelo pessoal da infra-estrutura para manter e fornecer um "help" em primeiro nível, então atingimos o "equilíbrio" no desenvolvimento real de soluções.

• Anonymous
  August 26, 2008
  "Não tem que ser difícil" :) [],

• Anonymous
  August 28, 2008
  The comment has been removed

• Anonymous
  September 08, 2008
  Otavio, tudo vem do requerimento. Quem manda é o cliente. Ele vai pagar pelo trabalho prático ou por um trabalho mais minucioso? É óbvio que nosso papel é assistí-los nessas decisão, mas muitas vezes a decisão já está tomada quando chegamos ao cliente e muitas outras ele quer tomar a decisão sozinho, apesar de todas as opiniões. Dito isso, eu acho, entre outras coisas, que um bom software tem que ser fácil de manter, de estender e deve ter uma API compreensível. Nem vou falar de requerimentos de negócio, esses são óbviamente necessário, se não forem atendidos o aplicativo não serve. Sinto que quando simplificamos demais o software fica engessado. Desacoplamento, por exemplo, traz complexidade. Mas alto acoplamento traz dificuldade de testes e manutenção. Eu prefiro a primeira opção. Agora, se o cliente possui uma equipe de manutenção toda júnior, o que é cada vez mais frequente, não dá para fazer um projeto complexo. Resultado: voltamos à mediocridade. Até pegando no que o Ramon falou, "não tem que ser difícil". Mas essa é uma medida complexa. Não é difícil para quem? Para um jr, quase tudo é complicado... Por isso voltamos ao começo: quem manda é o cliente. Um abraço, Giovanni Bassi