Arquitetos devem escrever código?

Olá

Vale a pena ler o blog do Tom Ball no java.net de hoje: Is Writing Code a Career Limiting Move?

[]s
Luca

ainda não li o post do cara, mas só a minha opinião rapidinho

pelo menos eu tenho que escrever código ...
por dois motivos:
1 - para evitar de morrer de tédio

2 - o mais importante --- se eu não usar a arquitetura que eu criei, pelo menos eu, tenho tendencia a viajar demais e criar um troço que mais atrapalha do que ajuda

Arquitetos que não programam (e eu conheço alguns) tendem a adotar "soluções" que mais causam problemas do que ajudam no projeto. Fora adotar coisas que não fazem o menor sentido ou sem um propósito definido para o desenvolvimento.

Thread.start() Membro desde: 03/08/2006 18:23:20 Mensagens: 29 Offline

um bom arquiteto sempre está programando em seus projetos OpenSource. é raríssimo vc ver um arquiteto q programa em projetos pessoais, etc.

Arquitetos programam sim, a própria arquitetura! No minimo pra juntar as ferramentas.

Sobre provar a própria comida de cachorro: é normal o arquiteto também ser desenvolvedor então é facil de programar e testar o que fez.

No meu caso que trabalho 100% do tempo como arquiteto, não consigo testar a arquitetura de maneira como o desenvolvedor, acho bem dificil.

Para resolver esse problema tento estar sempre junto dos desenvolvedores. Atualmente existem 3 empresas diferentes usando a arquitetura e elas sabem que podem relatar bugs diretamente pra mim e sugerir melhorias. Eu estou sempre perguntando se o modo de programar não está repetitivo (sinal que posso melhorar a arquitetura), analiso os códigos para ver se os desenvolvedores não estão sendo induzidos a fazer coisas erradas e por ai vai.

Eu vejo o arquiteto como uma figura necessária em um projeto com muitos code monkeys, caso contrário ele passa a ser meramente decorativo.

Arquitetos são os que podem mais afundar um projeto, vomitando uma arquitetura e deixando para traz um bando de gente a merce de um treco inominavel.

Por isso um arquiteto que não escreve código, ou pelo menos não está em constante contato com as vítimas daquilo que produz, só produz lixo.

louds wrote:pelo menos não está em constante contato com as vítimas daquilo que produz

pois é, vitimas é bom! hehe

marcelomartins wrote:

louds wrote:pelo menos não está em constante contato com as vítimas daquilo que produz

pois é, vitimas é bom! hehe

Vítimas sim, uma vez eu trampei num projeto falido pro Bostão em que o arquiteto de uma consultoria AAA (começa com S e termina com a) criou um framework incrivelmente estúpido, e todos os desenvolvedores foram punidos a usá-lo.

O melhor é que muitas vezes o arquiteto não tem a menor idéia do que está fazendo, no projeto em questão, tinhamos SLSB retornando enormes xmls para serem renderizados via xpath em jsps usando umas tag libs péssimas.

Qualquer um com um mínimo de competência sabe dizer que essa decisão é MUITO infeliz, ainda assim, o todo poderoso arquiteto defecou a arquitetura do projeto e saiu fora.

Por sorte eu pulei fora daquilo antes da fase de tunning, imagine tunnar uma nhaca dessa???

Eu sinceramente acho que o papel de arquiteto tem que morrer, precisamos hoje mesmo de technical leads, que fazer muito mais que produzir 1 monte de UML e ferrar e produtividade dos projetos, mas tb supervisionar os code monkeys o tempo todo com ferramentas como PMD, checkstyle & cia.

louds wrote:

marcelomartins wrote:

louds wrote:pelo menos não está em constante contato com as vítimas daquilo que produz

pois é, vitimas é bom! hehe

Vítimas sim, uma vez eu trampei num projeto falido pro Bostão em que o arquiteto de uma consultoria AAA (começa com S e termina com a) criou um framework incrivelmente estúpido, e todos os desenvolvedores foram punidos a usá-lo.

O melhor é que muitas vezes o arquiteto não tem a menor idéia do que está fazendo, no projeto em questão, tinhamos SLSB retornando enormes xmls para serem renderizados via xpath em jsps usando umas tag libs péssimas.

Qualquer um com um mínimo de competência sabe dizer que essa decisão é MUITO infeliz, ainda assim, o todo poderoso arquiteto defecou a arquitetura do projeto e saiu fora.

Por sorte eu pulei fora daquilo antes da fase de tunning, imagine tunnar uma nhaca dessa???

Bem, tua experiencia nesse caso da um embasamento pra tua opinião, mas não é bom generalizar, não acho que o papel de todo arquiteto seja ferrar a produtividade do desenvolvedor, e também não acho que todo desenvolvedor seja code monkey como tu diz.

Acho que no meu caso, no lugar de vítimas eu colocaria pessoas que entendem muito mais do que eu das regras de negócio da empresa e isso é realmente importante para a empresa.

E mais, também é importante para a empresa, garantir que o trabalho realizados por terceiros sejam de boa qualidade, e sigam conforme as regras especificadas. Muita gente diz que é impossivel garantir o trabalho de outras pessoas, mas isso é possivel sim. Um bom framework pode garantir que: ou a coisa fica boa, ou não sai. O lado ruim disso é que amarra um pouco o desenvolvedor e inibe a criatividade, isso é fato e conheço essa questão.

Fazem dois anos que eu estou bem envolvido com a parte tecnica do desenvolvimento mas sem ser desenvolvedor e conheço o lado negro das pessoas que definem a arquitetura: começam a achar que são Deuses, que sabem mais que qualquer um, a achar que a opinião dos outros não é válida, e pensar no desenvolvedor como um inimigo que deve ser combatido e amarrado. Em todas apresentações que eu faço e em cada treinamento que eu dou eu deixo bem claro, que o mais importante é o desenvolvedor se sentir bem usando a arquitetura e não ficar pensando que poderia fazer melhor e ficar me xingando. Se acha que pode fazer melhor senta do meu lado e vamos fazer.

louds wrote:Eu sinceramente acho que o papel de arquiteto tem que morrer, precisamos hoje mesmo de technical leads, que fazer muito mais que produzir 1 monte de UML e ferrar e produtividade dos projetos, mas tb supervisionar os code monkeys o tempo todo com ferramentas como PMD, checkstyle & cia.

Acho que o papel do technical leads importante também, mas é um visão mais especifica de um grupo de desenvolvedores. Acho que o arquiteto precisa de uma visão mais corporativa, e com problemas diferentes. technical leads talvez não tenham a visão de metodologia, integração de sistemas, auditorias e coisas mais.

louds wrote:Eu sinceramente acho que o papel de arquiteto tem que morrer, precisamos hoje mesmo de technical leads, que fazer muito mais que produzir 1 monte de UML e ferrar e produtividade dos projetos, mas tb supervisionar os code monkeys o tempo todo com ferramentas como PMD, checkstyle & cia.

+1

Experiência própria. Um technical lead consegue muito mais contato com a equipe, e justamente por ser um líder e não um chefe (chefes mandam, líderes lideram...), a equipe tende a discutir e concordar mais facilmente com o que é dito. Parece que só o fato de não existir o nome "arquiteto" o pessoal não encherga o fulano como monstro.

louds wrote:...

Simplesmente um cara aqui queria que usássemos XmlBeans nos projetos. Pedi pra ele explicar porque e ele falou que num futuro, se fóssemos integrar com outras aplicações seria mais fácil.

Fácil como se ele falou pra usar sem mesmo saber pra direito aquilo serve e como utilizar bem.

Fiz sem e depois avisei ele.

Bom senhores, vou responder como Arquiteto, pois exerço tal papel no banco francês - BNP Paribas e respondo pela arquitetura no conselho mundial do banco - América Latina.

Ter experiência como programador é fundamental e um dos preceitos do processo de certificação Sun Microsystems. Entretanto vivenciar as regras do negócio da companhia é papel do programador, pois muitas vezes o mesmo é especialista num nicho de mercado onde você ficaria meses ou anos para aprender.

Meu papel dentro da mesma é projetar a infra que os programadores vão utilizar, levando em conta muitos fatores:

Business plan da companhia - sim, pois preciso saber qual é a taxa de crescimento que o projeto estará esperando, a fim de provisionar uma arquitetura que consiga dar vasão à demanda. - Picos, como está´o hardware, vai suportar ? qual estratégia de failover usar ? Como fica o cluster, quantos nós, replicação da sessão, conectores, quantos sistemas estarão integrados, protocolos, segurança, performance e por ai vai ....

Expertise dos profissionais da casa, pois não adianta eu colocar o XPTO Y IOC na ponta, se minha equipe não está preparada. Será necessário um coaching e mentoring e ter consciência para projetar a evolução paulatina até o ideal.

Programar realmente as partes mais difícieis, principalmente quando se está adotando algum framework / processo que sua equipe ainda não está famirializada. Isso acaba validando sua arquitetura junto à mesma e se ganha o respeito dos membros, pois vêem sua idéia e o raciocínio e acaba ententendo os porquês.

Programar o dia-a-dia da companhia não faz parte realmente do escopo e sim programação de alto nível, voltada à itens não funcionais, infra e etc.

Entretanto, até mesmo para eu validar novos conceitos, acabo pegando projetos dentro da companhia para programar juntamente.

Com isso acabo ganhando muitas coisas: Valido minha arquitetura e muitas vezes acabo lapidando, queimando algumas coisas, acrescentando outras que não tive visão, pois projetar no UML é uma coisa completamente diferente de colocar a mão na massa.

Ganho, pois a galera acaba vendo o treco funcionando por quem bolou e fica empolgada em utilizar.

E por fim me sinto parte do "Time", pois posso provisionar à equipe um mentoring com cases reais de implementação e da empresa, cenário que eles conhecem !!

Recentemente fiz um refactoring numa aplicação. Foi muito empolgante mostrar o quadro : "antes " e "depois".

Surgem muitas dúvidas que você responde e acaba mostrando ao desenvolvedor que você não é um arquiteto alienígena, e sim um cara que tem um pouco mais de vivência, transfere know-how e muitos acabam pegando gosto pela coisa e comprando livros que você recomenda e se tornando arquitetos junto contigo, discutindo patterns, arquiteturas e até mesmo assumindo projetos em parceria

Quando não existem code monkeys o arquiteto geralmente assume postura de facilitador de decisões arquiteturais e programador da framework de infra-estrutura utilizado, se algum.

Quando estão numa consultoria commodity geralmente eles criam templates ("mecanismos arquiteturais") sobre como salvar objetos, fazer buscas, etc. além dos requisitos não funcionais. Também são a quem se pergunta absolutamente tudo que não envolva o que está coberto nos tais mecanismos, incluindo coisas que um programador deveria saber.

Ou seja: para consultorias commodity arquitetos são babás.

Falando em tudo isso, vi um link no blog do rafael muito bom:

The Principle Of Too Much Magic

louds wrote:Por isso um arquiteto que não escreve código, ou pelo menos não está em constante contato com as vítimas daquilo que produz, só produz lixo.

Onde é que eu assino!

Sou vitima de um framework não usado pelo arquiteto que projetou/desenvolveu.

valeuz...

Notícias, artigos e o maior fórum brasileiro sobre Java