Já sou programador certificado scjp e quero estudar para arquiteto porem, sem perder tempo com besteiras.
Qual o caminho a seguir? Sei que vou precisar do GOF, EJB e Spring
quantos projetos de verdade você já atuou?
[quote=jjose]Já sou programador certificado scjp e quero estudar para arquiteto porem, sem perder tempo com besteiras.
Qual o caminho a seguir? Sei que vou precisar do GOF, EJB e Spring
[/quote]
Quer ser arquiteto? Faz faculdade de arquitetura e se arruma no CREA. 8)
Mas, falando sério: O que é mais importante para um arquiteto é a estrutura do sistema, portando já mergulhe de cabeça no que é mais importante: Domain Driven Design e Test Driven Development.
GoF também ajuda. Aprender frameworks da moda você faz depois (ou não).
Vc pode usar o método Constanza, que tem esse nome inspirado no personagem George Constanza, do seriado Seinfield. Ele não era arquiteto, mas vivia dizendo que era.
Então começe a assinar emails e post como arquiteto que quando vc ver, todo mundo vai penasr que vc é um. :lol: :lol:
[quote=victorwss][quote=jjose]Já sou programador certificado scjp e quero estudar para arquiteto porem, sem perder tempo com besteiras.
Qual o caminho a seguir? Sei que vou precisar do GOF, EJB e Spring
[/quote]
Quer ser arquiteto? Faz faculdade de arquitetura e se arruma no CREA. 8)
Mas, falando sério: O que é mais importante para um arquiteto é a estrutura do sistema, portando já mergulhe de cabeça no que é mais importante: Domain Driven Design e Test Driven Development.
GoF também ajuda. Aprender frameworks da moda você faz depois (ou não).[/quote]
Um arquiteto se forma com teoria e prática. Vai precisar lidar com diversos protocolos, problemas de comunicação, técnicas de design de software e por aí vai. Um conselho é literatura, comece pelos principais arquitetos - Eric Evans como citado, Martin Fowler, Thomas Erl, Neal Ford, Andrew Hunt da série pragmática e por aí vai.
Precis estar com a mente aberta à novas metodologias e tecnologias como SOA ( BPM, BPA, BPEL, JBI JCA, ESBs, Repositories) , conceitos de transacionalidade, cluster e loadbalance, grid e por aí vai.
Um arquiteto se forma ao longo do tempo, então não tenha pressa e saiba que esse caminho leva aproximadamente uns 10 anos pra chegar lá ou mais :-).
para ser um arquiteto de titulo nao há segredos! Faça as certificacoes da sun, ate a de arquiteto e pronto! (antes leia como ela cobra e o quanto tera q estudar)
Lembrando que na certificacao da sun de arquiteto ela cobra um poquinho de cada area. movel, j2ee, j2se, padroes de projeto etc…
agora lembre-se o mercado nao quer o arquiteto apenas com titulo… a experiencia é fundamental(isso ja é cobrado desde programador junior qto mas para arquiteto) e apenas uma pequena experiencia e sim uma boa experiencia em um projeto solido.
E um arquiteto é so tecnico, há outras qualidades que se adquire com tempo, com relacionamento etc. Assim lembrando que ter ingles fluente(nao somente na leitura/escrita) eh um ponto forte no arquiteto.Não vejo vaga de arquiteto sem pedir ingles fluente, ate pq a maioria dos projetos envolve ir para fora do BR, mas nao so por isso nao. E outro detalhe na vaga solicita no minimo ai 5 para cima como experiencia e informar sua participação no projeto.
flw! espero ter ajudado 
[quote=Kenobi][quote=victorwss][quote=jjose]Já sou programador certificado scjp e quero estudar para arquiteto porem, sem perder tempo com besteiras.
Qual o caminho a seguir? Sei que vou precisar do GOF, EJB e Spring
[/quote]
Quer ser arquiteto? Faz faculdade de arquitetura e se arruma no CREA. 8)
Mas, falando sério: O que é mais importante para um arquiteto é a estrutura do sistema, portando já mergulhe de cabeça no que é mais importante: Domain Driven Design e Test Driven Development.
GoF também ajuda. Aprender frameworks da moda você faz depois (ou não).[/quote]
Um arquiteto se forma com teoria e prática. Vai precisar lidar com diversos protocolos, problemas de comunicação, técnicas de design de software e por aí vai. Um conselho é literatura, comece pelos principais arquitetos - Eric Evans como citado, Martin Fowler, Thomas Erl, Neal Ford, Andrew Hunt da série pragmática e por aí vai.
Precis estar com a mente aberta à novas metodologias e tecnologias como SOA ( BPM, BPA, BPEL, JBI JCA, ESBs, Repositories) , conceitos de transacionalidade, cluster e loadbalance, grid e por aí vai.
Um arquiteto se forma ao longo do tempo, então não tenha pressa e saiba que esse caminho leva aproximadamente uns 10 anos pra chegar lá ou mais :-). [/quote]
concordo com o kenobi e discordo do victorws no seguinte: framewok é coisa de desenvolvedor, tal como DDD e TDD já que “Developement” e “Design” são responsabilidades do desenvolvedor. Concordo com a diferença teoria-pratica. Arquiteto tem que entender de tecnologias genércias e requisitos não-funcionais como o kenobi mencionou. Não sei como vc vai ter estomago para isso tudo sem ser um bom desenvolvedor primeiro.
Se vc quer apenas tirar a certificação Sun de arquiteto isso são outros 500. Isso lhe dá uma certificação de arquiteto “junior” , é a experiencia em projetos reais que o torna um arquiteto realmente.
[quote=sergiotaborda][quote=Kenobi][quote=victorwss][quote=jjose]Já sou programador certificado scjp e quero estudar para arquiteto porem, sem perder tempo com besteiras.
Qual o caminho a seguir? Sei que vou precisar do GOF, EJB e Spring
[/quote]
Quer ser arquiteto? Faz faculdade de arquitetura e se arruma no CREA. 8)
Mas, falando sério: O que é mais importante para um arquiteto é a estrutura do sistema, portando já mergulhe de cabeça no que é mais importante: Domain Driven Design e Test Driven Development.
GoF também ajuda. Aprender frameworks da moda você faz depois (ou não).[/quote]
Um arquiteto se forma com teoria e prática. Vai precisar lidar com diversos protocolos, problemas de comunicação, técnicas de design de software e por aí vai. Um conselho é literatura, comece pelos principais arquitetos - Eric Evans como citado, Martin Fowler, Thomas Erl, Neal Ford, Andrew Hunt da série pragmática e por aí vai.
Precis estar com a mente aberta à novas metodologias e tecnologias como SOA ( BPM, BPA, BPEL, JBI JCA, ESBs, Repositories) , conceitos de transacionalidade, cluster e loadbalance, grid e por aí vai.
Um arquiteto se forma ao longo do tempo, então não tenha pressa e saiba que esse caminho leva aproximadamente uns 10 anos pra chegar lá ou mais :-). [/quote]
concordo com o kenobi e discordo do victorws no seguinte: framewok é coisa de desenvolvedor, tal como DDD e TDD já que “Developement” e “Design” são responsabilidades do desenvolvedor. Concordo com a diferença teoria-pratica. Arquiteto tem que entender de tecnologias genércias e requisitos não-funcionais como o kenobi mencionou. Não sei como vc vai ter estomago para isso tudo sem ser um bom desenvolvedor primeiro.
Se vc quer apenas tirar a certificação Sun de arquiteto isso são outros 500. Isso lhe dá uma certificação de arquiteto “junior” , é a experiencia em projetos reais que o torna um arquiteto realmente. [/quote]
A questão dos frameworks da moda eu coloquei em segundo plano exatamente porque não é de fundamental importância. Porém, o arquiteto tem que conhecê-los para saber do que são e do que não são capazes, quais as limitações e quais as alternativas.
TDD é importante, pois sistemas que tem arquitetura para as quais é difícil escrever-se testes são comuns, e é necessário conhecer-se a TDD para entender o porque (eu mesmo estou apenas nos primeiros contatos com ela, mas conheço a sua importância).
E quanto a DDD, discordo de você, acho que design é mais responsabilidade do arquiteto do que do desenvolvedor (se os dois não forem a mesma pessoa).
Uma coisa tem que ser dita:
Arquiteto de Software tem que conhecer Hardware também!
Essa é a definição de Arquiteto de Software: Arquiteto é programador, analista, desenvolvedor e ainda analisa o hardware necessário para funcionar a aplicação!
(pelo menos isso foi o que disse meu professor que programava em 1970 e foi evoluindo junto com as linguagens…+ de 30 anos de experiencia como programador!)
[quote=claudneto]Uma coisa tem que ser dita:
Arquiteto de Software tem que conhecer Hardware também!
Essa é a definição de Arquiteto de Software: Arquiteto é programador, analista, desenvolvedor e ainda analisa o hardware necessário para funcionar a aplicação!
(pelo menos isso foi o que disse meu professor que programava em 1970 e foi evoluindo junto com as linguagens…+ de 30 anos de experiencia como programador!)[/quote]
Precisa ter uma boa visão de Hardware e OS, como fazer para olhar vazamento de memória - Solaris DTrace, Applications Servers também, pois há muita configuração que pode detonar sua aplicação.
[quote=victorwss][quote=sergiotaborda]
concordo com o kenobi e discordo do victorws no seguinte: framewok é coisa de desenvolvedor, tal como DDD e TDD já que “Developement” e “Design” são responsabilidades do desenvolvedor. Concordo com a diferença teoria-pratica. Arquiteto tem que entender de tecnologias genércias e requisitos não-funcionais como o kenobi mencionou. Não sei como vc vai ter estomago para isso tudo sem ser um bom desenvolvedor primeiro.
[/quote]
A questão dos frameworks da moda eu coloquei em segundo plano exatamente porque não é de fundamental importância. Porém, o arquiteto tem que conhecê-los para saber do que são e do que não são capazes, quais as limitações e quais as alternativas.
TDD é importante, pois sistemas que tem arquitetura para as quais é difícil escrever-se testes são comuns, e é necessário conhecer-se a TDD para entender o porque (eu mesmo estou apenas nos primeiros contatos com ela, mas conheço a sua importância).
E quanto a DDD, discordo de você, acho que design é mais responsabilidade do arquiteto do que do desenvolvedor (se os dois não forem a mesma pessoa).[/quote]
Vc está usando a palavra “arquitetura” como sinônimo de " estrutura de classes, bibliotecas e contratos: fornecer features" enquanto eu estou usando a palavra com significado de “escolha de tecnologias, divisão da solução em sistemas , divisão dos sistemas em aplicações, escolha de protocolos de comunicação, escolha de servidores: fornecer estrutura”
A sua forma de ver “arquitetura” é muito baseada em requisitos funcionais , codigo e design. A minha é baseada em requisitos não-funcionais: disponibilidade, performance, distribuição, até SLA e licenciamentos…
Do seu ponto de vista eu concordo que TDD e DDD e frameworks etc… são importantes e fazem parte. O que eu não concordo é que chame a isso de “arquitetura” e à pessoa que faz isso “arquiteto” quando isso são responsabilidades do desenvolvedor.
Veja, se o que diz fosse responsabilidade do arquiteto, quem seria responsável pelas partes que eu explicitei ? O arquiteto tb ? ( nesse caso não haveria distinção entre desenvolvedor e arquiteto , já todo o mundo seria arquiteto).
O arquiteto raramente precisa saber sobre o negocio ( requisitos funcionais) ele precisa saber muito mais sobre as expectativas não funcionais. É o desenvolvedor que transforma requisitos funcionais em codigo. É ele que lida com as entidades, persistencia, valdiação, etc… ( por isso ele precisa de DDD, TDD, Design Patterns … )
Sérgio, interessante seu ponto em dizer que o arquiteto é responsável pelos requisitos não funcionais (concordo plenamente), porém ele não deveria também se preocupar com os requisitos funcionais? Não digo a parte de implementação (apesar que para mim, o arquivo deve estar envolvido com o código de alguma forma), mas no quesito de escolha de ferramentas, frameworks, metodologias e etc? Por exemplo, o arquito diz: Para esse projeto, vamos utilizar TDD, DDD, Pair Programing, EJB3. Para o Projeto Y, o Pair Programing não é necessário e vamos apenas utilizar Swing e Spring… Isso não seria o papel do arquiteto também?
Sérgio, interessante seu ponto em dizer que o arquiteto é responsável pelos requisitos não funcionais (concordo plenamente), porém ele não deveria também se preocupar com os requisitos funcionais? Não digo a parte de implementação (apesar que para mim, o arquivo deve estar envolvido com o código de alguma forma), mas no quesito de escolha de ferramentas, frameworks, metodologias e etc? Por exemplo, o arquito diz: Para esse projeto, vamos utilizar TDD, DDD, Pair Programing, EJB3. Para o Projeto Y, o Pair Programing não é necessário e vamos apenas utilizar Swing e Spring… Isso não seria o papel do arquiteto também?[/quote]
Quanto a mim não. Ele tem poder de veto das ferramentas que o desenvolvedor escolher se isso afetar os requisitos não funcionais ( performance, tempo de resposta, escalabilidade , etc… ) mas ele não pode - tiranicamente - decidir. Ele pode falar algo assim "Não use hibernate porque ele não é clusterizável e precisamos usar clusters para suportar os milões de acessos simultaneoas que teremos " ( é um exemplo, nem sei se é) É mais nesse sentido. Pair Programins , TDD , DDD completamente fora da responsabilidade dele.
Ele não se importa se o programa é feito a um, dois, três ou se é mágicamente criado , desde que cumpra os requisitos está bom.
Testes ? Só se for de performance, carga, etc… testes unitários não importam nada para uma visão macro que por definição não é únitária. Domain Design ? Modele como quiser.
Eu não estou a dizer que não ha uma conversa entre o arquiteto e o desenvolvedor e cada uma dá um palpite e um pitaco no que outro fala, o que estou dizendo é que a responsabilidade de cada um é diferente.
EJB é diferente. EJB é uma tecnologia. Usar ou não EJB pode ferir ou ajudar algum dos requisitos. Por exemplo, se o sistema não tem trnsacionalidade distribuida pessada, EJB é inutil. A maioria dos sistemas não precisa disso. No caso de EJB não ser um requisito e estar no mesmo patamar que , digamos, Spring, é o desenvolvedor que tem responsabilidade de escolher, já que isso afetará o design do codigo e não o como o sistema se comporta face a carga etc… claro que o arquiteto pode dizer algo como " nos 20 projetos que trabalhei com Spring tivemos problemas de escalabilidade acima de X usuários e tivemos que acabar usando uma amaração com EJB depois. Acho que é melhor já pensar nisso agora." Mas não é ele que vai dicidir. Ele só vai dicidir se X for menor que Y sendo Y o requisito: “Não vamos usar Spring porque ele não escala até Y usuários”
Em resumo, o arquiteto pode forçar o uso ou não uso de alguma coisa baseado exclusivamente em critérios de estrutura ( performance, carga, protocolo, etc…) nunca face a equipe, metodologia de desenvolvimento ou gerencia. O desenvolvedor dicidir as bibliotecas que vai usar e como elas funcionam juntas. Ambos devem conversas e acertas os ponteiros, mas no fim são responsabilidades diferentes. Veja assim , o arquiteto está preocupado com o que usuário vai sentir ao usar a aplicação ( lentidão, visual tosco - ergonomia tb é coisa de arquiteto - indisponibilidade, erros de exactidão, etc…) o desenvlvedor se preocupa com o que le vai fazer ( cadastrar usuário, receber email, acionar um processo, etc… )
Esse texto realmente resume muito bem. Ficou muito claro para mim.
Embora eu nunca achei que o arquiteto deveria IMPOR quais frameworks, metodologias, ferramentas devem ser usadas ou não, eu acho que é importante ele trabalhar juntamente com os desenvolvedores para definir um ambiente apropriado para cumprir os requisitos do sistema. E como você mesmo disse, cada um tem responsabilidade diferente dentro do projeto. Apesar que eu acho que seria interessante um arquivo também estar envolvido com o código, envolvido diretamente com os desenvolvedores e etc.
Sérgio, interessante seu ponto em dizer que o arquiteto é responsável pelos requisitos não funcionais (concordo plenamente), porém ele não deveria também se preocupar com os requisitos funcionais? Não digo a parte de implementação (apesar que para mim, o arquivo deve estar envolvido com o código de alguma forma), mas no quesito de escolha de ferramentas, frameworks, metodologias e etc? Por exemplo, o arquito diz: Para esse projeto, vamos utilizar TDD, DDD, Pair Programing, EJB3. Para o Projeto Y, o Pair Programing não é necessário e vamos apenas utilizar Swing e Spring… Isso não seria o papel do arquiteto também?[/quote]
Quanto a mim não. Ele tem poder de veto das ferramentas que o desenvolvedor escolher se isso afetar os requisitos não funcionais ( performance, tempo de resposta, escalabilidade , etc… ) mas ele não pode - tiranicamente - decidir. Ele pode falar algo assim "Não use hibernate porque ele não é clusterizável e precisamos usar clusters para suportar os milões de acessos simultaneoas que teremos " ( é um exemplo, nem sei se é) É mais nesse sentido. Pair Programins , TDD , DDD completamente fora da responsabilidade dele.
Ele não se importa se o programa é feito a um, dois, três ou se é mágicamente criado , desde que cumpra os requisitos está bom.
Testes ? Só se for de performance, carga, etc… testes unitários não importam nada para uma visão macro que por definição não é únitária. Domain Design ? Modele como quiser.
Eu não estou a dizer que não ha uma conversa entre o arquiteto e o desenvolvedor e cada uma dá um palpite e um pitaco no que outro fala, o que estou dizendo é que a responsabilidade de cada um é diferente.
EJB é diferente. EJB é uma tecnologia. Usar ou não EJB pode ferir ou ajudar algum dos requisitos. Por exemplo, se o sistema não tem trnsacionalidade distribuida pessada, EJB é inutil. A maioria dos sistemas não precisa disso. No caso de EJB não ser um requisito e estar no mesmo patamar que , digamos, Spring, é o desenvolvedor que tem responsabilidade de escolher, já que isso afetará o design do codigo e não o como o sistema se comporta face a carga etc… claro que o arquiteto pode dizer algo como " nos 20 projetos que trabalhei com Spring tivemos problemas de escalabilidade acima de X usuários e tivemos que acabar usando uma amaração com EJB depois. Acho que é melhor já pensar nisso agora." Mas não é ele que vai dicidir. Ele só vai dicidir se X for menor que Y sendo Y o requisito: “Não vamos usar Spring porque ele não escala até Y usuários”
Em resumo, o arquiteto pode forçar o uso ou não uso de alguma coisa baseado exclusivamente em critérios de estrutura ( performance, carga, protocolo, etc…) nunca face a equipe, metodologia de desenvolvimento ou gerencia. O desenvolvedor dicidir as bibliotecas que vai usar e como elas funcionam juntas. Ambos devem conversas e acertas os ponteiros, mas no fim são responsabilidades diferentes. Veja assim , o arquiteto está preocupado com o que usuário vai sentir ao usar a aplicação ( lentidão, visual tosco - ergonomia tb é coisa de arquiteto - indisponibilidade, erros de exactidão, etc…) o desenvlvedor se preocupa com o que le vai fazer ( cadastrar usuário, receber email, acionar um processo, etc… )[/quote]
Eu não acho que seja só isso. O arquiteto tem que saber também como que o código funciona, quais são os problemas e porque que eles acontecm, tendo um conhecimento profundo do código inclusive. E não simples e puramente delegar isso ao desenvolvedor ou então fazer pouco caso. Ele tem que saber que “ah, o acesso da tela de relatórios gerenciais está lento porque o programa não usa uma estrutura de dados adequada, então vamos bolar uma forma melhor” e não simplesmente “ah, acesso da tela de relatórios gerenciais está lento, desenvolvedor arrume isso”. Arquiteto não é um cara que decide que tecnologias vão ser usadas, vê o que o cliente quer, delega para o desenvolvedor fazer e vê se o resultado está bom. O arquiteto tem que liderar o desenvolvimento, estar a par e a frente dele e garantir a qualidade do desenvolvimento que se reflete no código.
Esse texto realmente resume muito bem. Ficou muito claro para mim.
Embora eu nunca achei que o arquiteto deveria IMPOR quais frameworks, metodologias, ferramentas devem ser usadas ou não, eu acho que é importante ele trabalhar juntamente com os desenvolvedores para definir um ambiente apropriado para cumprir os requisitos do sistema. E como você mesmo disse, cada um tem responsabilidade diferente dentro do projeto. Apesar que eu acho que seria interessante um arquivo também estar envolvido com o código, envolvido diretamente com os desenvolvedores e etc.[/quote]
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. Contudo, não vejo problema em a mesma pessoa ter papeis difentes em pontos diferentes do projeto. No inicio ele é arquiteto, no fim ele é programador. Aliás o que se procura é ter uma pessoa Desenvovledor Analista que possa incluir tanto os papeis de desenvolvedor, como de arquiteto como de analista. O único problema com isso é que é demasiada responsabilidade para uma pessoa só. Coisa que ninguém paga direito.
[quote=victorwss]
Eu não acho que seja só isso. O arquiteto tem que saber também como que o código funciona, quais são os problemas e porque que eles acontecm, tendo um conhecimento profundo do código inclusive. E não simples e puramente delegar isso ao desenvolvedor ou então fazer pouco caso. Ele tem que saber que “ah, o acesso da tela de relatórios gerenciais está lento porque o programa não usa uma estrutura de dados adequada, então vamos bolar uma forma melhor” e não simplesmente “ah, acesso da tela de relatórios gerenciais está lento, desenvolvedor arrume isso”. Arquiteto não é um cara que decide que tecnologias vão ser usadas, vê o que o cliente quer, delega para o desenvolvedor fazer e vê se o resultado está bom. O arquiteto tem que liderar o desenvolvimento, estar a par e a frente dele e garantir a qualidade do desenvolvimento que se reflete no código.[/quote]
Se a tela está lenta agora, é porque o arquiteto falhou no inicio durante a discussão com o desenvovedor e deixou o desenvovedor usar uma idéia que não funcionava. Quem sabe os truques para fazer as coisas irem mais rápido é o desenvolvedor sim. É da responsabilidade dele que o codigo escrito esteja no nivel desejado.
O que eu quero dizer é que o arquiteto não fica feito urubu em cima do desenvovledor. O arquiteto define a arqutietura e os testes necessários para garantir os requisitos não-funcionais, por exemplo seta o JMeter para certos parametros.
O desenvolvedor ignorando esses parâmetros irá codificar para que o teste passe. É dessa forma que o arquiteto controla. Quem tem que correr atrás é o desenvolvedor. O código é responsabilidade dele.
O arquiteto não tem que liderar. Quem tem que liderar é o Lider. Pode ser a mesma pessoa que desempenhou o papel de arquiteto, ou não, não importa. O Lider tem responsabilidades diferentes do arquiteto e do desenvolvedor. Para começar, ele tem, por exemplo, que moralizar a equipe.
Lembremo-nos que as pessoas não são X ou Y , elas representam o papel de X ou Y conforme as circunstâncias.
Ou seja, o arquiteto o desenvolvedor, o lider, o gerente e o programador podem ser todos o mesmo cara. Isso é possivel, mas não é recomendado. As responsabilidades de cada papel às vezes são antagónicas e a menos que pessoas desenvolva multiplas personalidades, ela irá ter problemas consigo mesma. normalmente, para a pessoa se livrar desses problemas ela cede ao mais fácil e o sistema vira gambiarra. É por isso que a probabilidade de um sistema ser gambiarra é tanto maior quanto menos pessoas ha na equipe ( quanto menos os papeis estão distribuídos)
Algo interessante, por exemplo, é que o Arquiteto do projeto X seja o desenvolvedor do projeto Y e lider do Z. Desta forma as capacidades da pesssoa são todas a aproveitadas mas não ha conflito de interesses ( aka corrupção , aka gambiarra).
[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.
Esse texto realmente resume muito bem. Ficou muito claro para mim.
Embora eu nunca achei que o arquiteto deveria IMPOR quais frameworks, metodologias, ferramentas devem ser usadas ou não, eu acho que é importante ele trabalhar juntamente com os desenvolvedores para definir um ambiente apropriado para cumprir os requisitos do sistema. E como você mesmo disse, cada um tem responsabilidade diferente dentro do projeto. Apesar que eu acho que seria interessante um arquivo também estar envolvido com o código, envolvido diretamente com os desenvolvedores e etc.[/quote]
Tem um ditado que resume bem isso:
- o programador é o cara que se preocupa com o que acontece quando 1 pessoa clica num botão;
- o arquiteto é o cara que se preocupa com o que acontece quando 1000 pessoas clicam num botão;