Passos para Arquiteto?

Assuntos Gerais
#21

[quote=victorwss][quote=sergiotaborda]Acho que vc quiz dizer que o arquiteto deve estar envolvido com o codigo.
Sim e não. Se ele fizer isso as decisões não serão imparciais no sentido que não serão apenas baseadas nos requisitos. Ele vai escolher o que é mais facil. Ou seja, irá corromper o sistema.[/quote]

O que você disse é em geral uma visão bem interessante, mas isto daí que você citou é uma falácia. Se o cara escolher o mais fácil é porque ele é simplesmente preguiçoso e não está fazendo o trabalho dele corretamente. Dizer que se ele estiver envolvido no código vai corromper o sistema é um absurdo. Tentação para ir do jeito mais fácil e preguiçoso e enfiar gambiarra todo mundo tem, mas não é só porque ele vê o código que ele vai ceder a isso. Muito pelo contrário, o fato dele estar uma espécie de QA no código do desenvolvedor evita que ocorram gambiarras ou que o desenvolvedor tome decisões erradas na codificação.[/quote]

Veja, se o cara não mexe no código que ele definiu ele não tem como cair em tentação. O ponto está em poder ou não cair e não se cai realmente. Por outro lado, na hora que ele é programador ele não é arquiteto. Se ele é QA não é programador.
Como arquiteto é provavelmente um não-programador é possivel que ele faça mais gambiarras que o verdadeiro programador porque ele não está habituado. Ou seja, ele vai trabalhar contra o que ele mesmo especificou. Tlv vc parta do principio que o arquiteto sabe programar na linguagem usada. Eu não parto desse principio porque a linguagem não é um fator na hora de escolher a arquitetura ( a plataforma sim, a linguagem não)

Eu entendo a sua idéia de “policiamento” que o arquiteto deveria manter do código, mas não concordo. Isso é o papel do desenvolvedor. Se o desenvovedor for ruim, o sistema não passa no teste definido pelo arquiteto , é tão simples assim. Se passa no teste não importa como ele passa. Ou seja, não importa funciona, desde que funcione.

O papel de verificar se por exemplo o checkstyle ou PMD está sendo respeitado , se os padrões estão bem implementados , etc… é do desenvolvedor ( na realidade é de todos os programadores, mas quem puxa a orelha é o desenvovledor)

#22

[quote=sergiotaborda][quote=victorwss][quote=sergiotaborda]Acho que vc quiz dizer que o arquiteto deve estar envolvido com o codigo.
Sim e não. Se ele fizer isso as decisões não serão imparciais no sentido que não serão apenas baseadas nos requisitos. Ele vai escolher o que é mais facil. Ou seja, irá corromper o sistema.[/quote]

O que você disse é em geral uma visão bem interessante, mas isto daí que você citou é uma falácia. Se o cara escolher o mais fácil é porque ele é simplesmente preguiçoso e não está fazendo o trabalho dele corretamente. Dizer que se ele estiver envolvido no código vai corromper o sistema é um absurdo. Tentação para ir do jeito mais fácil e preguiçoso e enfiar gambiarra todo mundo tem, mas não é só porque ele vê o código que ele vai ceder a isso. Muito pelo contrário, o fato dele estar uma espécie de QA no código do desenvolvedor evita que ocorram gambiarras ou que o desenvolvedor tome decisões erradas na codificação.[/quote]

Veja, se o cara não mexe no código que ele definiu ele não tem como cair em tentação. O ponto está em poder ou não cair e não se cai realmente. Por outro lado, na hora que ele é programador ele não é arquiteto. Se ele é QA não é programador.
Como arquiteto é provavelmente um não-programador é possivel que ele faça mais gambiarras que o verdadeiro programador porque ele não está habituado. Ou seja, ele vai trabalhar contra o que ele mesmo especificou. Tlv vc parta do principio que o arquiteto sabe programar na linguagem usada. Eu não parto desse principio porque a linguagem não é um fator na hora de escolher a arquitetura ( a plataforma sim, a linguagem não)

Eu entendo a sua idéia de “policiamento” que o arquiteto deveria manter do código, mas não concordo. Isso é o papel do desenvolvedor. Se o desenvovedor for ruim, o sistema não passa no teste definido pelo arquiteto , é tão simples assim. Se passa no teste não importa como ele passa. Ou seja, não importa funciona, desde que funcione.

O papel de verificar se por exemplo o checkstyle ou PMD está sendo respeitado , se os padrões estão bem implementados , etc… é do desenvolvedor ( na realidade é de todos os programadores, mas quem puxa a orelha é o desenvovledor) [/quote]

Bem, temos duas visões diferentes do que um arquiteto vem a ser:

  1. Você acha que ele não necessita saber programar na linguagem especificada.
  2. Eu acho que ele deve saber programar melhor do que ninguém na linguagem especificada.

Em todos os outros aspectos, acho que concordamos com o papel do arquiteto, a divergência está neste ponto.
Se bem que não existe nenhum lugar onde haja uma definição formal e bem rígida sobre o que ele é. Então, acredito que poderíamos ficar discutindo isso eternamente ad infinitum. O fato é: não existe apenas um única tipo de arquiteto que faz um conjunto X de coisas e acabou. Você está falando na variante de arquiteto A e eu na variante B. Outras variantes devem existir por aí também que fazem alguma coisa a mais ou alguma coisa a menos.
É isso.

#23

[quote=victorwss]
Bem, temos duas visões diferentes do que um arquiteto vem a ser:

  1. Você acha que ele não necessita saber programar na linguagem especificada.
  2. Eu acho que ele deve saber programar melhor do que ninguém na linguagem especificada.

Em todos os outros aspectos, acho que concordamos com o papel do arquiteto, a divergência está neste ponto.
Se bem que não existe nenhum lugar onde haja uma definição formal e bem rígida sobre o que ele é. Então, acredito que poderíamos ficar discutindo isso eternamente ad infinitum. O fato é: não existe apenas um única tipo de arquiteto que faz um conjunto X de coisas e acabou. Você está falando na variante de arquiteto A e eu na variante B. Outras variantes devem existir por aí também que fazem alguma coisa a mais ou alguma coisa a menos.
É isso.[/quote]

Só vi a sua mensagem hoje…

Realmente é essa a diferença entre as opiniões.
Agora tome nota do seguinte : Um arquiteto tem que escolher tecnologias que cumpram os requisitos não-funcionais do sistema.
Estas tecnologias podem ser muito diferentes do que vc e eu estamos habituados. Ele pode ter que recorrer a produtos especificos para a area em que o sistema atuará. Acho que vc concorda com isto. A
gora imagine que a sua regra é válida e o arquiteto tem que saber muito bem programar na plataforma escolhida. Bom, então isso significa que: ele só pode escolher tecnologias que domina completamente.
Obviamente isso é contrário ao objetivo principal do arquiteto.

O arquiteto não coloca a mão na massa. Baseado nos requisitos levantados pelo analista o arquiteto procura e escolhe a tecnologia que melhor se adequa ao sistema. Por exemplo, mesmo sem ter programado nunca em ruby eu nunca escolheria rubi para sistema de alta performance devido a relatos de que ele não escala bem. Mas para um protótipo seria aceitável. O mesmo para Groovy, por exemplo. Eu não escolheria uma interface web para um sistema com alta demanda de inserção de dados e sim algo como swing já que o ambiente web é inseguro por construção e nem sempre javascript e css ( e portanto ajax) estão disponíveis. E mesmo quando estão nem sempre ajudam muito. Por exemplo, teclas de atalha em javascript é um ó! Eu nunca escolheria Clipper, VB 6 , Delphi ou PHP para um projeto no panorama atual. E isso eu faço sem saber programar nessas plataforma. (Claro que existem exceções - se sua equipa so programa em clipper , fazer o quê ? despedi-los a todos ?)
Eu não preciso saber programar muito bem em javascritp , ruby, groovy, php, delphi , etc… para fazer estas escolhas.
Se eu precisar de um produto de streaming de audio eu não preciso conhecer , dominar e ter escrito o código do produto para o poder usar. Basta que existam algumas garantias como documentação farta, comunidade sociável e uso por outros partes ( peer review).

Arquitetura está um nivel acima de código assim como analise está acima de tecnologia. Tlv seja difícil para um desenvolvedor ou programador aceitar que ele não tem capacidade/poder para decidir certas coisas e que é necessário alguem com uma visão mais geral. Atualmente é raro se verem arquitetos verdadeiros inclusos nos projetos. O que vemos são Desenvolvedores Analistas que fazem suas escolhas muito rapidamente em base das tecnologias que conhecem. E junto com isso vemos programas que não escalam, que têm manutenção complexa, etc…

tudo bem que não ha uma carta magna definindo o que é um arquiteto de software, mas se vale alguma coisa, dê uma olhada nos objetivos para as certificações de desenvovledor e de arquiteto da sun. embora o arquiteto sun seja um tipo especifico de arquiteto muito ligado à plataforma java, dá para ver que não existem objetivos relacionados à linguagem em lugar algum.

Finalmente: Se o arquiteto sabe programar bem na linguagem causa, ótimo. Não digo que isso seja impeditivo para se ser arquiteto.
O que digo é que é impossível vc conhecer todas as plataformas com esse grau de conhecimento para fazer as suas escolhas.
Se fosse fácil ser arquiteto, todo o mundo seria.

#24

Estou errado ao afirmar que,na “vida real”,a tecnologia que mais se adequa ao sistema é a que a equipe do projeto domina?Com budgets e prazos cada vez mais apertados,como um arquiteto pode impor uma linguagem nova para os membros da equipe e colher resultados satisfatórios,sem tempo para treinamento e maturação de pessoal?

#25

[quote=raf4ever]Estou errado ao afirmar que,na “vida real”,a tecnologia que mais se adequa ao sistema é a que a equipe do projeto domina?
[/quote]

Sim.

[quote]
Com budgets e prazos cada vez mais apertados,como um arquiteto pode impor uma linguagem nova para os membros da equipe e colher resultados satisfatórios,sem tempo para treinamento e maturação de pessoal? [/quote]

Você está falando em exceções. O fato da equipe disponível não saber programar a estrutura escolhida pelo arquiteto significa que essa equipa não pode programar aquele sistema e não que o arquiteto tem que olhar a equipe e escolher outras tecnologias.
O papel do arquiteto é agradar ao usuário final, não ao cliente nem aos programadores.

Agora, podem existir constangimentos conforme o contexto eas circunstancias a que o arquiteto está sujeito.
Nesse caso o arquiteto será instruído a criar “a melhor arquitetura para o sistema que seja compativel com a equipe”. Repare que isso é pedir muito. Muito mesmo.

Mas à medida que as plataformas padrão ( java, net, etc…) ganham dos seus concorrentes menos uniformizados e mais antigos é mais fácil que o arquiteto possa escolher livremente. contudo isso nem sempre é verdade. Imagine o arquiteto que tem que fazer uma integração com sistema de URA e o unico produto do mercado só permite interação com .NET (só um exemplo). Por muito que o arquiteto ou a equipe prefiram java, não ha nada a fazer.

#26